Unisender Go: email-рассылка из своего приложения

Пользователь зарегистрировался, оплатил заказ или запросил код входа — и ждёт подтверждения. Если приложение ничего не прислало, для него действие будто исчезло: непонятно, создан ли аккаунт, прошла ли оплата и что делать дальше. Разберём, как подключить Unisender Go, чем сервис отправки отличается от обычного почтового ящика и что проверить до первого настоящего письма.

Зачем приложению вообще отправлять письма

Письмо — это след события, который остаётся у пользователя за пределами приложения. Страница с надписью «Готово» закроется, уведомление внутри сайта можно не заметить, а письмо сохранится во входящих и к нему можно вернуться. Поэтому email нужен не только интернет-магазинам и большим компаниям. Он полезен почти любому приложению, в котором пользователь совершает важное действие.

Самые понятные примеры:

• Подтверждение регистрации. Человек получает ссылку и доказывает, что адрес принадлежит ему. Заодно он понимает, что аккаунт действительно создан.
• Код или ссылка для входа. Вместо пароля приложение отправляет одноразовый код либо специальную ссылку. Пользователю не нужно придумывать и запоминать ещё один пароль.
• Чек или подтверждение оплаты. После покупки человек видит сумму, состав заказа и данные продавца. Если письмо не пришло, даже успешная оплата начинает вызывать тревогу.
• Уведомление о заказе. Письмо сообщает, что заказ принят, передан в доставку, отменён или готов к выдаче.
• Восстановление доступа. Ссылка для смены пароля должна попасть только владельцу адреса и действовать ограниченное время, заданное самим приложением.
• Важное изменение. Например, сменился email аккаунта, завершился экспорт данных или администратор ответил на обращение.

Представь простое приложение с таблицей рекордов в «Змейке». Пока игрок просто набирает очки, письма ему не нужны. Но как только появляются аккаунты, вход с разных устройств или платный набор скинов, возникают события, которые нельзя оставлять без подтверждения. После регистрации стоит сообщить, что профиль создан. После покупки — подтвердить результат. После запроса на восстановление — дать безопасный путь обратно в аккаунт.

При этом отправлять письмо после каждого движения не нужно. Полезное правило: письмо оправдано, если событие влияет на доступ, деньги, заказ, безопасность или требует действия позже. Сообщение «ты открыл настройки» только создаст шум. Чем больше ненужных писем отправляет приложение, тем чаще получатели перестают их читать или отмечают как спам.

Почему нельзя просто отправлять письма со своего сервера

Технически сервер может попытаться отправить письмо самостоятельно. Но «передать текст в интернет» и «надёжно доставить письмо во входящие» — разные задачи. Почтовые службы каждый день отсекают огромный поток нежелательных сообщений, поэтому незнакомому отправителю они не доверяют автоматически.

Когда письмо приходит на сервер получателя, тот оценивает не только адрес в поле «От кого». Он пытается понять:

• разрешено ли этому серверу отправлять письма от имени указанного домена;
• снабжено ли сообщение корректной цифровой подписью;
• совпадают ли технические данные письма с заявленным отправителем;
• есть ли у отправляющего адреса и домена нормальная репутация;
• много ли писем с него отклоняют или отмечают как спам;
• существует ли адрес получателя и не было ли постоянных ошибок раньше;
• похоже ли содержание и поведение отправителя на нежелательную рассылку.

Допустим, твоё приложение работает на домене example.ru, а письмо подписано как hello@example.ru. Одной красивой строки недостаточно. Почтовая служба должна получить через DNS — публичные настройки домена — подтверждение, что конкретный почтовый сервис вправе отправлять сообщения от имени example.ru. Иначе злоумышленник мог бы так же легко подставить адрес любого банка, магазина или знакомого человека.

Для проверки используются механизмы аутентификации почты. Новичку важно понимать их смысл, а не запоминать все сокращения:

• SPF сообщает, какие серверы имеют право отправлять почту для домена.
• DKIM добавляет к письму цифровую подпись. Получатель сверяет её с открытым ключом в настройках домена и замечает подмену.
• DMARC задаёт общую политику проверки и помогает владельцу домена видеть, кто ещё пытается писать от его имени.

Кроме доменных записей нужен правильно настроенный почтовый сервер: очередь сообщений, повторные попытки при временной ошибке, обработка отказов, защита от дублей и наблюдение за репутацией. Если сервер получателя временно недоступен, письмо нельзя просто забыть. Если адрес не существует, не стоит бесконечно слать на него новые сообщения. Если один почтовый провайдер начал отклонять поток, нужно увидеть причину и скорректировать отправку.

Сервисы для рассылки email берут значительную часть этой работы на себя. Они предоставляют готовые серверы отправки, API, очереди, статистику и инструменты для обработки ошибок. Твоё приложение сообщает, кому и что нужно отправить, а сервис занимается транспортом. Настроить собственный домен всё равно придётся, но поднимать и круглосуточно обслуживать всю почтовую систему с нуля не нужно.

Что такое Unisender Go простыми словами

Unisender Go — российский сервис для отправки писем на email из приложений и других информационных систем. Приложение обращается к нему через API, передаёт адрес получателя, тему и содержимое, а сервис принимает сообщение, пытается доставить его и собирает события о результате.

API — это формальный способ общения программ друг с другом. Вместо того чтобы человек открывал почтовый сайт и вручную нажимал «Отправить», сервер приложения посылает структурированный запрос. Если само понятие пока непривычно, сначала прочитай объяснение что такое API, а затем возвращайся к примеру ниже.

Упрощённо роли распределяются так:

Например, игрок нажимает «Войти по коду» и вводит адрес. Приложение не должно отправлять письмо прямо из браузера: тогда секретный ключ API пришлось бы отдать каждому посетителю. Вместо этого браузер обращается к собственному серверу. Сервер создаёт одноразовый код, сохраняет его безопасное представление и просит Unisender Go отправить сообщение. Пользователь получает код и вводит его в приложении.

Путь сообщения можно представить так:

flowchart TB
    a["Действие пользователя в приложении"]
    b["Запрос к API сервиса"]
    c["Проверка домена и подписи"]
    d["Доставка почтовой службе"]
    e["Входящие"]
    f["Спам"]
    a --> b --> c --> d
    d --> e
    d --> f

Unisender Go поддерживает Web API и SMTP API. Web API — это запросы по HTTPS с данными в JSON, то есть в понятном программам текстовом формате. SMTP — стандартный почтовый протокол, с которым умеют работать многие готовые библиотеки и системы. Для нового приложения Web API обычно легче контролировать: у запроса и ответа ясная структура, а ошибки можно обрабатывать в коде. Если используемая платформа уже умеет отправлять только по SMTP, второй способ может потребовать меньше изменений.

Важно не путать принятие запроса и доставку. Ответ API говорит, что сервис понял запрос либо сразу нашёл в нём ошибку. После успешного приёма письмо ещё проходит очередь, сервер получателя и его фильтры. Поэтому приложение не должно показывать «Письмо уже во входящих» только на основании успешного ответа. Честнее написать: «Письмо отправлено. Если его нет, проверь папку “Спам” и попробуй ещё раз через минуту».

Чем транзакционные письма отличаются от массовой рассылки

Транзакционное письмо отправляется конкретному человеку в ответ на его действие или изменение, которое относится к его аккаунту. Человек зарегистрировался — получил подтверждение. Запросил вход — получил код. Оплатил заказ — получил информацию об оплате. Такое письмо является продолжением уже начатого сценария.

Массовая рассылка устроена иначе. Компания заранее собирает список подписчиков, а затем отправляет им новости, подборки, акции или обучающие материалы. Письмо не обязательно связано с действием, совершённым прямо сейчас. Один выпуск может уйти тысячам людей.

Разницу удобно видеть в таблице:

На массовые письма нужно согласие получателя. Нельзя взять адреса пользователей приложения и начать присылать им рекламу только потому, что они когда-то зарегистрировались или купили товар. Согласие должно быть осознанным: человек понимает, на какую рассылку подписывается. Также нужен понятный способ отказаться от неё.

Транзакционный характер письма не даёт разрешения прятать в нём рекламу. Если человек запросил код входа, письмо должно прежде всего содержать код, срок его действия и понятное предупреждение на случай, если запрос сделал кто-то другой. Большой рекламный блок внутри такого сообщения меняет ожидания пользователя и способен ухудшить жалобы и доставляемость.

Ещё одна причина разделять потоки — разная цена задержки. Новостной выпуск можно доставить чуть позже без серьёзного ущерба. Код входа, ссылка восстановления или подтверждение оплаты нужны сейчас. Если массовая кампания создаёт большую очередь и тормозит критичные сообщения, пользователь не сможет завершить действие. При проектировании полезно хотя бы логически отделить срочные транзакционные письма от маркетинговых.

Не смешивай и показатели. Для кода входа важнее доля доставленных сообщений и время до доставки. Для дайджеста дополнительно смотрят открытия, переходы и отписки. Открытие не всегда определяется идеально из-за настроек почтовых приложений, поэтому оно не должно быть единственным критерием качества.

Почему Unisender Go удобен российскому проекту

При выборе почтового сервиса важна не только документация API. Сервис становится частью рабочего процесса: его нужно оплачивать, учитывать в документах, давать к нему доступ сотрудникам и поддерживать годами. Для проекта из России Unisender Go часто удобнее зарубежного решения именно на этом бытовом уровне.

Основные практические причины:

• оплату можно организовать в рублях без зарубежной банковской карты;
• российскому бизнесу проще получить привычные закрывающие документы и согласовать сервис с бухгалтерией;
• для входа и работы не приходится строить процесс вокруг региональных ограничений;
• поддержка и документация доступны на русском языке;
• меньше риск, что критичная отправка остановится из-за невозможности продлить зарубежную подписку.

Зарубежные сервисы вроде Resend могут нравиться разработчику интерфейсом, библиотеками или примерами интеграции. Но техническое удобство — только один критерий. Если для оплаты требуется отдельная карта, а доступ к аккаунту зависит от внешних ограничений, это добавляет проекту новые точки отказа. Подготовку к таким подпискам мы отдельно разобрали в статье про зарубежную карту для оплаты сервисов.

Это не означает, что российский сервис автоматически лучше во всех проектах. У международного продукта могут быть аудитория в разных странах, особые требования к регионам инфраструктуры или уже готовая интеграция с другим поставщиком. Выбор зависит от реального сценария, а не от моды в примерах кода.

Для небольшого российского приложения здравый вопрос звучит так: «Сможем ли мы стабильно оплачивать, поддерживать и использовать этот канал через год?» Если ответ для Unisender Go проще и понятнее, это весомее небольшой разницы в синтаксисе одного API-запроса.

Как выбрать сервис email-рассылок

Запрос «как выбрать сервис email рассылок» часто приводит к таблицам с десятками функций. Новичку полезнее начать с собственного сценария. Составь список писем, которые появятся в приложении, и для каждого ответь: почему оно отправляется, насколько срочно, сколько получателей у него бывает и как ты узнаешь о недоставке.

Затем сравни сервисы по критериям, которые влияют на работу:

1. Назначение. Убедись, что сервис подходит для транзакционных писем через API, если нужны коды, чеки и уведомления. Один только визуальный редактор массовых кампаний эту задачу не решает.
2. Способ интеграции. Проверь наличие Web API, SMTP или готовой библиотеки для твоей платформы. Важнее не количество интеграций, а совместимость с тем, где работает сервер приложения.
3. Аутентификация домена. Сервис должен объяснять, какие DNS-записи добавить и как увидеть результат проверки. Без этого нормальный запуск невозможен.
4. Статистика и причины ошибок. Нужны не только общие числа, но и возможность понять, что произошло с конкретным письмом: принято, доставлено, временно отложено или окончательно отклонено.
5. Уведомления о событиях. Для автоматизации полезны вебхуки — запросы, которые почтовый сервис сам отправляет твоему серверу при доставке, отказе или другом событии.
6. Безопасность ключей и доступов. У команды должна быть возможность не раздавать один секрет всем подряд и менять скомпрометированный ключ.
7. Поддержка. При проблеме с доставкой важен содержательный ответ, а не только общая статья о спаме.
8. Оплата и документы. Проверь доступный способ оплаты, валюту, договор и документы, нужные твоей форме работы.
9. Масштабирование. Сопоставь предполагаемый объём, пики и рост с актуальными тарифами. Не покупай большой запас «на всякий случай», но и не игнорируй внезапные всплески после запуска.
10. Переносимость. Хорошо, когда логика приложения не размазана по десяткам мест. Отдельный модуль отправки позволит сменить поставщика без переписывания регистрации, заказов и восстановления доступа.

Не ищи обещание «100% во входящие». Ни один внешний отправитель не управляет окончательным решением почтовой службы получателя. Сервис может корректно подписать письмо, использовать устойчивую инфраструктуру и показать причину отказа, но содержимое, репутация домена и поведение твоей аудитории тоже влияют на результат.

Что нужно сделать до первой отправки

До подключения к API нужен домен, которым ты управляешь. Бесплатный личный адрес вроде project@gmail.com не подтверждает право приложения отправлять почту от имени собственного бренда. Лучше использовать адрес на своём домене: например, no-reply@example.ru для автоматических сообщений или support@example.ru, если на ответы действительно будет реагировать поддержка.

В панели Unisender Go домен нужно добавить и подтвердить. Сервис выдаст DNS-записи, которые следует перенести в настройки домена у регистратора или DNS-провайдера. Названия разделов и внешний вид панели со временем меняются, поэтому ориентируйся на значения, показанные сервисом для твоего домена, а не копируй записи из чужой инструкции.

Общая последовательность такая:

1. Выбрать домен отправителя и адрес в поле «От кого».
2. Добавить домен в почтовый сервис.
3. Получить выданные сервисом записи для подтверждения владения и почтовой подписи.
4. Добавить эти записи в DNS именно того домена, с которого будут уходить письма.
5. Дождаться распространения изменений DNS.
6. Проверить в панели сервиса, что владение доменом и DKIM подтверждены.
7. Только после этого переходить к реальным получателям.

DNS можно представить как публичный справочник домена. Изменения кэшируются и не всегда появляются во всём интернете мгновенно. После сохранения проверь имя, тип и значение записи, затем дождись успешной проверки. Если домен уже отправляет почту через другие системы, не заменяй существующие записи вслепую: новая настройка должна учитывать всех разрешённых отправителей.

После подтверждения домена подготовь само письмо. У него должны быть:

• понятное имя отправителя;
• тема, соответствующая действию;
• текстовая версия, даже если основная часть оформлена в HTML;
• ясная кнопка или код без лишних отвлекающих блоков;
• объяснение, почему человек получил сообщение;
• работающая ссылка и корректный адрес для ответа, если ответ предполагается.

Для ссылок входа и восстановления используй случайные одноразовые токены с ограниченным сроком действия. Не вставляй в URL пароль пользователя и не храни сам секрет в открытом виде дольше, чем необходимо. Письмо передаётся через несколько систем и может остаться в ящике надолго, поэтому оно не должно раскрывать лишние данные.

Перед запуском проверь письмо на собственных адресах в нескольких популярных почтовых службах и на телефоне. Посмотри не только красоту: читается ли тема, виден ли код, ведёт ли кнопка на правильный домен, что произойдёт после повторного нажатия, не показывает ли приложение внутреннюю ошибку. Тестовые письма не заменяют доменную настройку, но помогают найти ошибки сценария до пользователей.

Как выглядит отправка через Unisender Go API со стороны кода

Со стороны приложения отправка состоит из двух запросов. Сначала браузер обращается к твоему серверу: например, просит прислать код входа. Затем сервер проверяет данные, создаёт код и обращается к Unisender Go API. Ключ доступа существует только на сервере.

Схема важнее конкретного языка:

1. Пользователь отправляет форму.
2. Сервер проверяет формат email и ограничивает частоту запросов.
3. Сервер создаёт одноразовый код или данные уведомления.
4. Сервер формирует тему, текстовую и HTML-версию письма.
5. Сервер читает API-ключ из переменной окружения.
6. Сервер отправляет HTTPS-запрос в Unisender Go.
7. Приложение сохраняет идентификатор операции и обрабатывает ответ.
8. События доставки попадают в статистику или возвращаются через вебхук.

Упрощённый серверный пример на JavaScript может выглядеть так:

const UNISENDER_GO_URL =
  'https://goapi.unisender.ru/ru/transactional/api/v1/email/send.json';

export async function sendLoginCode({ email, code }) {
  const response = await fetch(UNISENDER_GO_URL, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Accept: 'application/json',
      'X-API-KEY': process.env.UNISENDER_GO_API_KEY,
    },
    body: JSON.stringify({
      message: {
        recipients: [{ email }],
        subject: 'Код входа в приложение',
        from_email: 'no-reply@example.ru',
        from_name: 'Моё приложение',
        body: {
          plaintext: `Твой код входа: ${code}`,
          html: `<p>Твой код входа: <strong>${code}</strong></p>`,
        },
      },
    }),
  });

  const result = await response.json();

  if (!response.ok) {
    throw new Error(`Email API error: ${response.status}`);
  }

  return result;
}

Это пример формы запроса, а не готовая система входа. Перед применением сверь адрес метода и поля с актуальной документацией сервиса. В настоящем проекте нельзя подставлять пользовательский ввод прямо в HTML без обработки, записывать сам код в обычный лог или возвращать ответ внешнего API целиком в браузер.

Строка process.env.UNISENDER_GO_API_KEY означает: взять секрет из окружения, в котором запущен сервер. Сам ключ не находится в файле с кодом и не попадает в репозиторий. Подробнее этот принцип разобран в статье про хранение секретов и токенов.

Критически важно, чтобы этот код выполнялся на сервере, а не в браузере. Всё, что загружено на страницу, посетитель может увидеть через инструменты разработчика. Если положить API-ключ во фронтенд, посторонний человек сможет извлечь его и отправлять письма за счёт твоего аккаунта. Переменная с префиксом, который сборщик специально публикует в браузер, тоже не является секретной.

В бессерверной архитектуре роль сервера может выполнять серверная функция платформы или защищённая функция базы данных. Название технологии не меняет правило: ключ хранится только в доверенной среде, а публичный клиент обращается к ограниченному маршруту твоего приложения.

Сам маршрут тоже нужно защищать. Иначе злоумышленник сможет вызывать его тысячи раз, даже не зная ключа Unisender Go. Для формы кода входа нужны ограничение частоты, одинаковый нейтральный ответ для существующего и несуществующего аккаунта, срок жизни кода и запрет повторного использования. Ошибки обрабатывай по типам, а временные сбои повторяй ограниченно, чтобы не создать дубли.

И ещё раз: ответ 200 или другой успешный статус означает, что API принял запрос согласно своему протоколу. Он не означает, что пользователь уже увидел письмо. Фактическую доставку нужно определять по статистике и событиям сервиса.

Как проверить отправку до запуска

Проверка должна охватывать весь сценарий, а не только отдельную функцию sendLoginCode. Пользователь нажимает кнопку в браузере, запрос проходит через сервер, письмо отправляется, ссылка открывается, приложение принимает результат. Ошибка может появиться на любом участке.

Начни с небольшой таблицы сценариев:

Используй отдельное тестовое окружение и адреса, которыми управляешь. Не проверяй интеграцию на случайных людях. Отправь письмо на несколько своих ящиков у разных почтовых служб: одна может принять сообщение, а другая отфильтровать его иначе.

Затем пройди короткий чек-лист:

• домен и DKIM отмечены как подтверждённые;
• адрес отправителя относится к подтверждённому домену;
• API-ключ отсутствует в исходниках, истории Git и коде страницы;
• в технических логах нет кода входа, ключа API и полного содержимого чувствительных писем;
• текстовая и HTML-версии передают один и тот же смысл;
• ссылки используют HTTPS и ведут на ожидаемый домен;
• код или ссылка перестают работать после использования и по истечении срока;
• повторный запрос не создаёт неограниченное число писем;
• интерфейс не обещает доставку до получения соответствующего события;
• причина отказа видна разработчику, но внутренние детали не показываются пользователю.

После теста открой статистику Unisender Go и найди отправленное письмо. Сопоставь время, адрес и результат с логом своего приложения. В журнал приложения записывай безопасный внутренний идентификатор, тип письма и технический статус, но не секреты и не полное тело сообщения. Тогда при обращении пользователя можно связать событие приложения с событием почтового сервиса.

Если подключаешь вебхуки, проверяй входящие события способом из актуальной документации и учитывай возможные повторы. Не меняй статус заказа или оплаты из-за почтового события: доставка письма сообщает о письме, а не подтверждает бизнес-операцию.

Что делать, когда письма всё равно не доходят

Первое действие — не отправлять одно и то же письмо десятки раз. Повторы могут ухудшить ситуацию, раздражать получателя и затруднять поиск причины. Вместо этого проследи путь одного конкретного сообщения по времени, адресу и внутреннему идентификатору.

Проверяй по уровням.

Приложение создало запрос

Убедись, что пользователь действительно завершил действие, а сервер дошёл до функции отправки. Ошибка могла произойти раньше: форма не прошла проверку, сервер вернул исключение, код сработал только в другом окружении или очередь приложения остановилась.

Не выводи в лог API-ключ и полный одноразовый код. Для диагностики достаточно времени, типа сообщения, замаскированного адреса или внутреннего идентификатора и безопасного кода ошибки.

Unisender Go принял сообщение

Посмотри ответ API и статистику в панели. Если сервис отклонил запрос, причина часто связана со структурой данных, авторизацией, неподтверждённым отправителем или ограничением аккаунта. Не скрывай ошибку пустым catch: тогда интерфейс покажет успех, хотя письмо даже не было принято.

Если запрос принят, найди событие дальнейшей обработки. Между «принято API» и «доставлено серверу получателя» есть отдельные состояния. Временная проблема может привести к повторным попыткам, а постоянная — к окончательному отказу.

Почтовая служба получателя ответила ошибкой

В отчёте о недоставке ищи технический ответ сервера получателя. Он может сообщать, что адрес не существует, ящик переполнен, сообщение отклонено политикой или отправитель не прошёл проверку. Формулировки отличаются у разных служб, поэтому важен исходный ответ, а не догадка пользователя «наверное, опять спам».

Письмо принято, но его нет во «Входящих»

Попроси пользователя проверить «Спам», «Промоакции» и поиск по имени отправителя. Если письмо оказалось в спаме, проверь доменную аутентификацию, репутацию, содержание и ожидания аудитории. Огромные изображения, вводящие в заблуждение темы, сокращатели ссылок и несоответствие доменов могут вызывать дополнительное недоверие.

Не проси всех подряд нажимать «Не спам» как замену исправлению причины. Это может помочь конкретному получателю, но не чинит неподтверждённый домен, нежелательную базу или сломанную ссылку.

Получатель не ждал письмо

Даже идеально настроенная техника не спасёт рассылку, на которую люди не подписывались. Жалобы ухудшают репутацию и влияют на будущие сообщения, включая нужные транзакционные. Не покупай базы, не собирай адреса без понятной цели и не превращай служебные письма в рекламу.

Для массовой рассылки храни факт и источник согласия, делай отправителя узнаваемым и давай простой отказ. После отписки прекращай соответствующие маркетинговые письма. При этом осторожно отделяй их от действительно необходимых сообщений об аккаунте или заказе.

Проблема повторяется

Собери факты для поддержки: время отправки с часовым поясом, домен отправителя, домен получателя, безопасный идентификатор сообщения, статус и текст ошибки сервера получателя. Не отправляй в обращении API-ключ, пароль или действующий код входа. Конкретные данные помогут намного больше, чем фраза «почта не работает».

Когда вместо письма лучше SMS

Для кода входа иногда удобнее SMS. Телефон чаще находится рядом, уведомление заметнее, а пользователю не нужно открывать почтовое приложение. Особенно это полезно в сценариях, где номер телефона уже является основным идентификатором: доставка, запись на услугу или быстрый вход с мобильного устройства.

Но SMS не является универсально лучшим каналом. У него свои ограничения:

• каждое сообщение тарифицируется отдельно;
• доставка зависит от оператора и состояния мобильной сети;
• пользователь мог сменить номер или находиться в роуминге;
• короткий формат плохо подходит для подробного чека или инструкции;
• мошенническая замена SIM-карты и перехват доступа к номеру остаются отдельными рисками;
• отправителю всё равно нужны ограничение частоты, срок действия и защита от перебора кода.

Email лучше подходит для длинного подтверждения, чека, истории заказа и ссылки, к которой человек вернётся позже. SMS полезнее для короткого срочного сигнала. Иногда разумно использовать оба канала, но не посылать их одновременно без необходимости: это увеличивает расходы и шум.

Если основной сценарий — одноразовые коды по номеру телефона, посмотри отдельный разбор SMSC как SMS-шлюза для OTP. OTP означает одноразовый пароль. Архитектурный принцип останется знакомым: приложение обращается к внешнему сервису через сервер, секрет хранится в окружении, а отправка защищена от злоупотреблений.

Выбирать канал стоит по вопросу «что пользователю нужно сделать?». Для «введи шесть цифр прямо сейчас» SMS может быть удобнее. Для «сохрани подтверждение покупки и детали заказа» письмо обычно уместнее. А для критичных операций иногда нужен дополнительный, более сильный способ подтверждения — это уже отдельное решение безопасности, а не просто выбор транспорта.

Unisender Go: тарифы и лимиты

Точные цены, включённые объёмы и технические лимиты меняются. Поэтому бессмысленно зашивать их в архитектуру или ориентироваться на цифру из старого обзора. Актуальные Unisender Go тарифы и ограничения смотри на официальном сайте сервиса перед подключением и перед заметным ростом нагрузки.

Сравнивай не только стоимость одного письма. Посчитай весь сценарий:

• сколько транзакционных сообщений создаёт один активный пользователь;
• бывают ли резкие пики, например после запуска акции или массового сброса паролей;
• входят ли нужные способы получения статистики в выбранные условия;
• нужен ли отдельный проект, выделенная инфраструктура или дополнительная поддержка;
• как пополняется баланс и кто получит предупреждение о его окончании;
• какие документы нужны бухгалтерии;
• что произойдёт при достижении лимита.

Настрой уведомления о расходе и ошибках так, чтобы их видел ответственный человек, а не заброшенный ящик. Критичные письма не должны внезапно остановиться только потому, что никто не заметил ограничение тарифа или проблему с оплатой.

Если продукт растёт, периодически пересматривай условия. Подходящий тариф на старте может стать неудобным при другой нагрузке, а индивидуальные требования могут потребовать разговора с сервисом. Не оптимизируй стоимость раньше данных, но заранее сделай остановку отправки видимой для команды.

Частые вопросы

Unisender Go и обычный Unisender — одно и то же?

Это связанные продукты, но в контексте приложения Unisender Go рассматривают как транспорт для отправки писем через API или SMTP. Перед регистрацией проверь, что выбираешь продукт, рассчитанный на нужный тебе сценарий, а документацию читаешь именно для Unisender Go.

Нужен ли свой домен для первой настоящей рассылки?

Да, для нормальной отправки от имени приложения нужен домен, которым ты управляешь. Его подтверждают с помощью DNS-записей, а для писем настраивают подпись. Тестовая возможность сервиса не заменяет подготовку собственного отправителя к запуску.

Можно ли вызвать Unisender Go API прямо из браузера?

Нет, если запрос требует секретного API-ключа. Код страницы доступен посетителю, поэтому ключ быстро окажется снаружи. Браузер должен обращаться к защищённому маршруту твоего сервера или серверной функции, а уже она — к Unisender Go.

Успешный ответ API означает, что письмо доставлено?

Нет. Он подтверждает, что запрос принят или корректно обработан на этом этапе. Дальше письмо проходит очередь и сервер получателя. Результат доставки смотри в статистике и событиях; пользователь также может найти принятое письмо в спаме.

Можно ли отправлять рекламу всем зарегистрированным пользователям?

Нет. Регистрация сама по себе не означает согласие на массовую рекламную рассылку. Получай отдельное понятное согласие, объясняй содержание рассылки и предоставляй возможность отказаться. Транзакционное письмо используй по назначению, не маскируй под него рекламу.

Что выбрать для кода входа: email или SMS?

Зависит от продукта и привычного идентификатора пользователя. Email не требует платы за каждое SMS и подходит для ссылок и подробных сообщений. SMS часто быстрее замечают на телефоне, но у него отдельная стоимость, ограничения доставки и риски доступа к номеру. В обоих случаях код должен быть одноразовым, короткоживущим и защищённым от перебора.

Что важно запомнить

Unisender Go связывает действие в приложении с привычным для пользователя подтверждением во входящих. Приложение передаёт данные через API, сервис отправляет письмо и показывает события доставки, а почтовая служба получателя принимает окончательное решение о папке назначения.

Для надёжного запуска мало написать один fetch. Сначала подтверди собственный домен и настрой подпись, затем спрячь API-ключ в серверной переменной окружения, отдели транзакционные письма от массовых и пройди весь сценарий на тестовых адресах. После запуска следи не только за ответом API, но и за недоставками, жалобами и ожиданиями пользователей.

Если письмо помогает человеку понять, что регистрация, вход, оплата или заказ действительно состоялись, оно выполняет свою задачу. Если оно приходит без ожидания и пользы, даже хорошая техническая инфраструктура не превратит его в желанное.