Email API: полное руководство по программной отправке писем (2026)

Email API позволяет вашему приложению отправлять письма через HTTP-запросы.

Звучит просто, однако это решение влияет на надёжность продукта, доставляемость писем, рабочие процессы инженерной команды, аналитику, соответствие требованиям, клиентский опыт и работу службы поддержки.

В прежней версии этой страницы структура была верной, но глубины не хватало. Там сравнивались API, приводился короткий пример для Brevo и объяснялось, когда использовать API, а когда SMTP. Это обновление сохраняет ту же структуру и расширяет её до полного, исследованного руководства по внедрению, опирающегося на данные со страниц поставщиков, а также на актуальную документацию и страницы тарифов Brevo, SendGrid, Mailgun, Amazon SES, Postmark и на документацию собственного messaging API компании Tajo.

Краткий ответ

Используйте email API, когда вам нужны письма, которые инициирует само приложение:

• Подтверждение регистрации.
• Сброс пароля.
• Вход по одноразовой ссылке (magic link).
• Подтверждение заказа.
• Уведомление об отправке заказа.
• Счёт или чек об оплате.
• Приглашение в продукт.
• Онбординг во время пробного периода.
• Оповещение об использовании лимитов.
• Уведомление о неудачном платеже.
• Напоминание о продлении подписки.
• Автоматизация жизненного цикла на основе продуктовых событий.

Используйте SMTP, когда отправляющая система поддерживает только учётные данные SMTP или когда вам нужен стандартизированный транспортный слой почты для унаследованного приложения, плагина, сервера или внутреннего инструмента.

Выбор лучшего email API зависит от вашего технологического стека:

Не выбирайте провайдера только по цене на витрине. Стоимость email API включает также время инженеров, работу над доставляемостью, моделирование данных, мониторинг, поддержку и риск будущей миграции.

Email API против SMTP

И API, и SMTP умеют отправлять письма. Разница в том, как именно ваше приложение передаёт сообщение отправляющей платформе.

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

Email API: это HTTP-интерфейс. Ваше приложение отправляет запрос на конечную точку, передавая данные аутентификации, получателей, содержимое, данные для шаблона, метаданные, а иногда и параметры расписания или пакетной отправки.

Практическое правило: если код приложения принадлежит вам, начинайте с API. Если вы настраиваете сторонний инструмент, который поддерживает только SMTP, используйте SMTP.

Как работает email API

Базовый сценарий отправки состоит из семи шагов:

1. Ваше приложение создаёт событие, например user_signed_up или order_paid.
2. Приложение выбирает тип сообщения.
3. Приложение загружает данные получателя, отправителя, шаблона и персонализации.
4. Приложение отправляет аутентифицированный HTTP-запрос почтовому провайдеру.
5. Провайдер проверяет запрос и ставит сообщение в очередь.
6. Провайдер возвращает ответ с признаком успеха, ошибкой или идентификаторами сообщения.
7. Webhook-уведомления сообщают вашей системе о событиях доставки, отказа, клика, жалобы или отписки.

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

Быстрый старт: отправка письма через API Brevo

Транзакционный email API компании Brevo использует аутентифицированный запрос к конечной точке /v3/smtp/email. Конкретные SDK и названия полей могут меняться, поэтому при реализации считайте справочник API поставщика единственным источником истины.

Пример запроса:

curl --request POST \
  --url https://api.brevo.com/v3/smtp/email \
  --header 'api-key: YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --data '{
    "sender": {
      "name": "Your App",
      "email": "[email protected]"
    },
    "to": [
      {
        "email": "[email protected]",
        "name": "Customer"
      }
    ],
    "subject": "Welcome to your account",
    "htmlContent": "<h1>Welcome</h1><p>Your account is ready.</p>"
  }'

В production-коде не следует жёстко прописывать ключи API. Храните секреты в менеджере секретов или в переменных окружения, регулярно меняйте их, ограничивайте доступ и никогда не раскрывайте их во фронтенд-коде.

Архитектура промышленной интеграции с email API

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

Используйте небольшой слой обмена сообщениями:

1. Происходит продуктовое событие.
2. Приложение записывает событие в очередь, фоновую задачу или шину событий.
3. Почтовый сервис сопоставляет событие с шаблоном.
4. Почтовый сервис проверяет согласие получателя и правила подавления.
5. Почтовый сервис вызывает API провайдера.
6. Почтовый сервис записывает идентификатор сообщения, выданный провайдером.
7. Позже webhook-уведомления обновляют статус сообщения.

Такой подход сохраняет продуктовый код чистым и упрощает локализацию сбоев в отправке писем.

Рекомендуемые внутренние поля:

• event_id.
• message_type.
• recipient_id.
• recipient_email.
• template_id.
• locale.
• provider.
• provider_message_id.
• idempotency_key.
• status.
• error_code.
• created_at.
• sent_at.
• delivered_at.

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

Сравнение лучших email API

Brevo

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

Выбирайте Brevo, когда:

• Вам нужны транзакционные письма плюс кампании, CRM, автоматизация, SMS или WhatsApp.
• Данные электронной коммерции должны запускать сообщения жизненного цикла.
• Маркетинг и продуктовые сообщения должны использовать общие профили контактов.
• Доступ к шаблонам и отчётности нужен сотрудникам без навыков разработки.
• Вы хотите одну платформу, а не отдельные узкоспециализированные инструменты для каждого канала.

На что обратить внимание:

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

Документация Brevo охватывает транзакционную отправку, пакетную отправку, режим песочницы, SMTP-ретрансляцию, webhook-уведомления, SDK и справочник API. Используйте эти материалы для деталей реализации.

SendGrid

SendGrid: распространённый выбор для команд, которым нужен зрелый email API для разработчиков с широкой поддержкой языков и платформ.

Выбирайте SendGrid, когда:

• Разработчикам нужны привычный email API и экосистема SDK.
• Вам нужны транзакционные и маркетинговые письма от одного поставщика.
• У вас уже есть инфраструктура Twilio.
• Вам нужны webhook-уведомления о событиях и детальный контроль отправки.

На что обратить внимание:

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

Mailgun

Mailgun построен вокруг отправки, которой управляют разработчики, и рабочих процессов по принципу API-first.

Выбирайте Mailgun, когда:

• Почтовая инфраструктура находится в зоне ответственности инженерной команды.
• Вам нужны отправка по HTTP, резервный вариант через SMTP, журналы, маршруты для входящей почты и инструменты валидации адресов.
• Вам нужен провайдер, который открыто описывает свои процессы по доставляемости.

На что обратить внимание:

• Какие функции валидации, аналитики и доставляемости включены в тариф.
• Срок хранения данных и доступ к журналам.
• Чего ждать от поддержки во время миграции и прогрева отправки.

Amazon SES

Amazon SES ориентирован на инфраструктуру.

Выбирайте Amazon SES, когда:

• Ваше приложение уже активно работает на AWS.
• У вас есть инженерные ресурсы, чтобы взять на себя большую часть настройки.
• Вам нужна отправка больших объёмов с оплатой по факту использования.
• Вам нужна тесная интеграция с IAM, CloudWatch, SNS, Lambda или другими сервисами AWS.

На что обратить внимание:

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

SES может быть отличным решением при больших объёмах, но это не самый малозатратный вариант для каждой команды.

Postmark

Postmark сфокусирован на транзакционной почте.

Выбирайте Postmark, когда:

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

На что обратить внимание:

• Тарифные уровни при ваших объёмах отправки.
• Как долго вам нужно хранить события и сообщения.
• Стоит ли выносить массовый маркетинг в отдельный поток или на отдельную платформу.

Tajo

Tajo актуален тогда, когда отправка писем связана с электронной коммерцией, клиентскими событиями и автоматизацией на стороне Brevo.

Используйте Tajo, когда:

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

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

Когда использовать email API

Транзакционные письма

Транзакционные письма запускаются действием пользователя или системным событием.

Примеры:

• Подтверждение аккаунта.
• Вход по одноразовой ссылке (magic link).
• Сброс пароля.
• Двухфакторная аутентификация.
• Приглашение в продукт.
• Подтверждение заказа.
• Чек об оплате.
• Подтверждение отправки заказа.
• Обновление статуса доставки.
• Уведомление о возврате средств.
• Продление подписки.
• Оповещение о неудачном платеже.
• Уведомление о безопасности.

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

Смотрите также: письма с подтверждением заказа и примеры транзакционных писем.

Письма продуктового жизненного цикла

Письма жизненного цикла находятся между транзакционными и маркетинговыми.

Примеры:

• Онбординг во время пробного периода.
• Активация функции.
• Достижение показателя использования.
• Предложение перейти на более высокий тариф.
• Напоминание о неактивном аккаунте.
• Контрольное письмо от команды по работе с клиентами.
• Последовательность писем о продлении.
• Письмо для возврата ушедшего клиента.

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

Письма для электронной коммерции

Командам в электронной коммерции часто нужны и транзакционные, и запускаемые маркетингом письма:

• Приветственное предложение.
• Брошенная корзина.
• Брошенный просмотр товара.
• Товар снова в наличии.
• Снижение цены.
• Рекомендация товара.
• Напоминание о повторной покупке.
• Обновление в программе лояльности.
• Просьба оставить отзыв.
• Ранний доступ для VIP-клиентов.

Командам, работающим с Shopify и Brevo, Tajo помогает связать данные о заказах, клиентах, согласиях, товарах и корзинах, чтобы эти сообщения запускались реальным покупательским поведением.

Маркетинговые письма через API

Не сводите маркетинговую почту к пакетной рассылке новостей.

Маркетинг, запускаемый через API, поддерживает:

• Сегментацию на основе событий.
• Персонализированные кампании.
• Запускаемые по триггеру цепочки писем.
• Онбординг, ведомый самим продуктом.
• Сценарии жизненного цикла на уровне отдельных аккаунтов.
• Автоматические письма, привязанные к поведению клиентов.

Требования по соответствию нормам при этом никуда не исчезают. Маркетинговые сообщения требуют надлежащего согласия, обработки отказов от рассылки и правил подавления.

Ключевые возможности API, на которые стоит смотреть

Аутентификация и управление ключами

Серьёзный email API должен поддерживать безопасные ключи API и иметь понятную документацию по аутентификации.

Операционные требования:

• Разделяйте ключи по окружениям.
• Ограничивайте доступ к промышленным ключам.
• Регулярно меняйте ключи.
• Храните ключи за пределами кода.
• Журналируйте использование ключа, не записывая в журнал его значение.
• Удаляйте ключи из дампов неудачных запросов.

Шаблоны

Шаблоны обеспечивают единообразие транзакционных писем.

Ищите поддержку следующего:

• Версионирование.
• Тестовые отправки.
• Переменные.
• Значения по умолчанию для подстановки.
• Локализация.
• Предпросмотр отрисованного письма.
• Рабочие процессы согласования.
• Раздельные шаблоны для тестового и промышленного окружений.

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

Webhook-уведомления

Webhook-уведомления превращают отправку писем в замкнутый цикл обратной связи.

Отслеживайте следующие события:

• Обработано.
• Отложено.
• Доставлено.
• Открыто, с оговорками.
• Клик по ссылке, с оговорками.
• Отказ доставки.
• Отброшено.
• Жалоба на спам.
• Отписка.

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

Управление списками подавления

Обработка списков подавления защищает доставляемость и соответствие требованиям.

Система должна обрабатывать:

• Жёсткие отказы доставки (hard bounce).
• Жалобы на спам.
• Отписки.
• Ручные блокировки.
• Ролевые адреса, если ваша политика их исключает.
• Некорректные контакты.
• Удаление аккаунта или запросы по приватности данных.

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

Лимиты запросов и пропускная способность

Проверьте, как провайдер работает со следующим:

• Лимиты на количество запросов к API.
• Пропускная способность по сообщениям.
• Конечные точки для пакетной отправки.
• Лимиты на всплески нагрузки.
• Дневные или месячные лимиты тарифного плана.
• Прогрев нового аккаунта.
• Прогрев выделенного IP-адреса.

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

Аналитика и выгрузки

Минимальный набор отчётности:

• Отправлено.
• Доставлено.
• Отказы доставки.
• Отложено.
• Жалобы на спам.
• Отписки.
• Эффективность шаблонов.
• Ошибки в ответах провайдера.
• События выручки или конверсии, когда это уместно.

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

Разбор входящей почты

Входящая почта важна, когда пользователи отвечают на письма или отправляют содержимое внутрь продукта.

Сценарии использования:

• Ответы в службу поддержки.
• Создание заявок из писем.
• Ответ на комментарий по почте.
• Рабочие процессы согласования.
• Пересланные чеки и счета.
• Приём входящих заявок от потенциальных клиентов.

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

Доставляемость при работе через email API

API сам по себе не решает проблему доставляемости автоматически.

Вам всё равно нужны:

• SPF.
• DKIM.
• DMARC.
• Подтверждённые домены отправки.
• Единообразная идентичность отправителя.
• Чистые списки контактов.
• Обработка отказов доставки.
• Обработка жалоб на спам.
• Понятная отписка для маркетинговых сообщений.
• Релевантное содержимое.
• Разумная частота отправки.
• Мониторинг.

Для новых доменов или IP-адресов проводите постепенный прогрев. Начните с малорискованной почты с высокой вовлечённостью и увеличивайте объём по мере стабилизации репутации.

По возможности разделяйте типы сообщений:

• Аутентификация и безопасность.
• Чеки и обновления по заказам.
• Продуктовый жизненный цикл.
• Маркетинг.
• Массовые промоакции.

Не допускайте, чтобы агрессивная промокампания навредила доставке писем о сбросе пароля или чеков.

Обработка ошибок и повторные попытки

Сбои при обращении к email API нужно классифицировать.

Повторять попытку:

• Таймаут.
• Временная ошибка провайдера.
• Превышение лимита запросов, с задержкой перед повтором.
• Сетевой сбой.
• Временная проблема с очередью.

Не повторять бесконечно:

• Некорректный адрес получателя.
• Неавторизованный ключ API.
• Неверный идентификатор шаблона.
• Отсутствует обязательное поле.
• Получатель в списке подавления.
• Блокировка по политике или требованиям соответствия.

Используйте экспоненциальную задержку между попытками и очередь недоставленных сообщений (dead-letter queue) для тех писем, которые продолжают завершаться ошибкой после всех повторов.

У каждого критически важного письма должен быть операционный путь решения проблем:

• Может ли служба поддержки отправить его повторно?
• Может ли пользователь запросить его снова?
• Может ли инженерная команда отследить событие?
• Видите ли вы ответ провайдера?
• Можете ли вы доказать, что провайдер принял сообщение?

Чек-лист внедрения email API

Пройдите этот список перед запуском.

1. Определите типы сообщений и ответственных за них.
2. Выберите провайдера API и запасной вариант отправки.
3. Подтвердите домены отправителя.
4. Настройте SPF, DKIM и DMARC.
5. Создайте отдельные ключи API для тестового и промышленного окружений.
6. Храните секреты безопасно.
7. Постройте почтовый сервис или адаптер.
8. Добавьте ключи идемпотентности.
9. Добавьте структурированные журналы.
10. Реализуйте повторные попытки и очередь недоставленных сообщений.
11. Создайте шаблоны.
12. Проверьте персонализацию и значения по умолчанию.
13. Настройте webhook-уведомления.
14. Сохраняйте идентификаторы сообщений от провайдера.
15. Обрабатывайте отказы доставки, жалобы и отписки.
16. Постройте инструменты поддержки для повторной отправки и проверки статуса.
17. Отслеживайте долю ошибок и долю доставленных писем.
18. Задокументируйте лимиты запросов и сценарии реагирования на инциденты.

Оценочная таблица для выбора провайдера

Оцените каждого поставщика по шкале от 1 до 5:

Для многих команд правильный ответ: это не «самый дешёвый email API». Это провайдер, который снижает операционные риски для тех типов писем, от которых зависят клиенты.

Типичные ошибки

Избегайте следующего:

• Отправка писем напрямую из разрозненных мест в коде приложения.
• Запись в журнал ключей API или полных полезных нагрузок с персональными данными.
• Повторные попытки при любой ошибке, как если бы она была временной.
• Игнорирование идентификаторов сообщений от провайдера.
• Откладывание webhook-уведомлений до момента, когда поддержка спросит «а письмо вообще дошло?».
• Смешивание писем о сбросе пароля и массового маркетинга на одном и том же репутационном канале.
• Использование одного шаблона для всех языковых версий.
• Отсутствие значений по умолчанию для переменных в шаблоне.
• Восприятие открытий как доказательства доставки или успеха клиента.
• Ситуация, когда логика маркетинговой отписки подавляет обязательные письма о безопасности аккаунта без осознанно принятой политики.
• Сравнение провайдеров только по бесплатному тарифу.
• Запуск больших объёмов отправки без прогрева.

С чего начать

Для нового внедрения выбирайте самый короткий безопасный путь:

1. Начните с одного транзакционного письма, например со сброса пароля или подтверждения заказа.
2. Постройте адаптер провайдера вместо того, чтобы жёстко связывать продуктовый код с одним поставщиком.
3. Добавьте аутентификацию домена.
4. Добавьте отслеживание статусов через webhook-уведомления.
5. Добавьте прозрачность для службы поддержки.
6. Добавьте шаблоны и локализацию.
7. Расширяйтесь до автоматизаций жизненного цикла и электронной коммерции.

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

Если вместо этого вам нужна настройка SMTP, смотрите полное руководство по SMTP и руководство по бесплатным SMTP-серверам.

Смежные руководства

• Руководство по сервисам транзакционной почты
• Примеры транзакционных писем
• Полное руководство по SMTP
• SPF, DKIM и DMARC
• Руководство по автоматизации email-рассылок
• Интеграция Brevo и Shopify