Email API · 21 сентября 2026 г.
Бесплатного тарифа SendGrid больше нет: миграция за 30 минут
Бесплатный тариф SendGrid теперь — 60-дневный пробный период. Техническое руководство для инженеров: как перенести транзакционные письма на устойчивую альтернативу без простоя.
Конец вечно бесплатного тарифа
Если вы использовали бесплатный тариф SendGrid для небольшого пет-проекта или нового продукта, вы наверняка заметили изменение: бесплатный тариф теперь — 60-дневный пробный период. После его окончания придётся перейти на платный тариф; Essentials стоит от 19.95 USD в месяц (цены SendGrid). Для миграции нужно выгрузить стоп-лист, обновить DNS-записи и заменить интеграцию с API. Если шаблоны простые, это займёт около 30 минут.
Оцениваем альтернативы
Выбирая замену, различайте приём провайдером (API принял ваш запрос), доставку (принимающий сервер принял письмо) и попадание во «Входящие» (письмо не оказалось в «Спаме»). Последнее не может гарантировать ни один провайдер: оно зависит от вашей репутации отправителя и содержания писем.
Цены на рынке (сентябрь 2026 г.)
Для транзакционной почты с небольшим объёмом разница в цене существенна. Отправка 50 000 писем стоит примерно 5 USD в Amazon SES с оплатой по факту и около 66 USD на тарифах Postmark.
- Amazon SES: 0.10 USD за 1 000 писем при оплате по факту (цены AWS SES). Новые многоуровневые тарифы, введённые 21 июля 2026 года: Essentials (0.16 USD за 1 000), Pro (0.22 USD за 1 000 плюс 105 USD в месяц за регион) и Enterprise (0.23 USD за 1 000 плюс 500 USD в месяц).
- Resend: бесплатный тариф на 3 000 писем в месяц, не более 100 в день. Тариф Pro — 20 USD в месяц за 50 000 писем, превышение — 0.90 USD за 1 000 (цены Resend).
- Mailgun: от 15 USD в месяц за 10 000 писем, превышение — от 1.80 до 1.10 USD за 1 000 (цены Mailgun).
- Postmark: от 15 USD в месяц за 10 000 писем, превышение — от 1.80 до 1.20 USD за 1 000 (цены Postmark).
- SendHQ: современная альтернатива для продуктовых команд и ИИ-агентов с упором на минимизированную телеметрию с хранением только в ЕС и API-ключи в рамках рабочего пространства.
Шаг 1. Выгрузка данных и стоп-листа
Не переносите список, не выгрузив стоп-лист. Если отправить письмо на адрес, который ранее дал отказ или отписался, вы рискуете испортить репутацию у нового провайдера.
SendGrid позволяет выгрузить стоп-лист через интерфейс или API. Вы получите CSV с адресами, на которые нельзя писать. При импорте к новому провайдеру правильно сопоставьте «причину» (отказ или отписка), чтобы соблюдать требования законов вроде GDPR или CAN-SPAM.
Шаг 2. DNS и аутентификация
Именно здесь проваливается большинство миграций. Недостаточно просто сменить API-ключ: нужно доказать новому провайдеру, что домен принадлежит вам.
DKIM, SPF и DMARC
Вам нужно добавить новые CNAME- или TXT-записи у DNS-провайдера. Если вы переходите на SendHQ, проверьте текущую настройку перед изменениями с помощью Email DNS Checker.
- SPF: добавьте нового провайдера в SPF-запись. Если вы используете несколько провайдеров, помните, что SPF TXT-запись может быть только одна. Их нужно объединить в одну (например,
v=spf1 include:sendgrid.net include:_spf.sendhq.cc ~all). Подробнее — в термине глоссария SPF. - DKIM: сгенерируйте новые ключи DKIM в панели управления нового провайдера и добавьте полученные CNAME-записи в DNS. Так принимающий сервер сможет убедиться, что письмо не было изменено в пути.
- DMARC: политика DMARC не зависит от провайдера, так как задаётся на уровне домена. Однако убедитесь, что новый провайдер выровнен с вашей политикой DMARC, иначе письма могут отклоняться. Подробности настройки — в руководстве по DKIM, SPF и DMARC.
Шаг 3. Миграция кода
Большинство провайдеров используют REST API. Если вы пользовались динамическими шаблонами SendGrid, нужно перенести эти HTML/CSS-макеты в шаблонизатор нового провайдера.
Пример: с SendGrid на обычный REST API
SendGrid использует особую JSON-структуру для personalizations. Большинство современных API, включая SendHQ, предпочитают более плоскую структуру, которую проще читать.
Полезная нагрузка SendGrid:
{
"personalizations": [
{
"to": [{"email": "user@example.com"}],
"dynamic_template_data": {
"first_name": "Alice"
}
}
],
"from": {"email": "noreply@yourdomain.com"},
"template_id": "d-12345"
}
Полезная нагрузка современного API (например, SendHQ):
{
"to": "user@example.com",
"from": "noreply@yourdomain.com",
"template_id": "welcome-email",
"variables": {
"first_name": "Alice"
}
}
Миграция в коде
Чтобы избежать простоя, реализуйте обёртку или паттерн «Стратегия». Это позволит переключаться между провайдерами с помощью переменной окружения.
interface EmailProvider {
send(payload: EmailPayload): Promise<void>;
}
class SendGridProvider implements EmailProvider {
async send(payload: EmailPayload) {
// SendGrid specific implementation
}
}
class SendHQProvider implements EmailProvider {
async send(payload: EmailPayload) {
// SendHQ specific implementation
}
}
const provider = process.env.EMAIL_PROVIDER === 'sendhq'
? new SendHQProvider()
: new SendGridProvider();
Шаг 4. ИИ-агенты и идемпотентность
Если письма отправляют ИИ-агенты, возникает особый риск: из-за тайм-аута агент может зациклиться или повторить запрос несколько раз, и пользователь получит десять одинаковых писем.
Отправка письма — внешний побочный эффект. Нужно обеспечить идемпотентность. Ключ идемпотентности — это уникальный идентификатор в заголовке, который говорит API: «Если ты уже видел этот ключ, не отправляй письмо повторно, просто верни исходный успешный ответ».
Реализация, готовая к работе с агентами:
{
"headers": {
"Idempotency-Key": "order_123_welcome_email"
},
"body": {
"to": "customer@example.com",
"template_id": "order-confirmation"
}
}
Кроме того, для рискованных действий агента (например, отправки письма для сброса пароля или уведомления об оплате) добавьте этап согласования человеком или строгий лимит запросов на ID пользователя, чтобы галлюцинации агента не превратились в спам для ваших клиентов.
Шаг 5. Тестирование и проверка
Прежде чем переключить переменную окружения на нового провайдера, пройдите по этому чек-листу:
- Распространение DNS: с помощью
digили веб-чекера убедитесь, что новые DKIM- и SPF-записи уже действуют. - Проверка вебхуков: если вы используете события доставки (delivered, opened, clicked), обновите эндпоинты вебхуков. Формат событий SendGrid отличается от других. Убедитесь, что эндпоинт справляется с новой JSON-схемой и не падает.
- Обработка ошибок: проверьте, как приложение обрабатывает ошибки конкретного провайдера. Например, 429 (Too Many Requests) должна запускать стратегию задержки, а 400 (Bad Request) обычно указывает на некорректный email-адрес, который нужно пометить в базе данных как отказ.
Типичные ошибки, которые стоит проверить
- Неверный формат адреса: убедитесь, что API возвращает понятную ошибку, а ваш код не повторяет запрос бесконечно.
- Ограничение частоты запросов: сымитируйте всплеск отправки и проверьте, выдерживает ли ваша очередь лимиты провайдера.
- Крупные вложения: уточните максимальный размер полезной нагрузки у нового провайдера. Одни ограничивают её 10 МБ, другие — 25 МБ.
Итоговый чек-лист миграции
- Экспорт стоп-листа: экспорт CSV из SendGrid.
- Настройка DNS-записей: выравнивание SPF, DKIM и DMARC.
- Перенос шаблонов: преобразуйте HTML/CSS в новый формат.
- Обновление API-логики: реализуйте обёртку провайдера.
- Добавление идемпотентности: необходимо для триггеров ИИ-агента.
- Тестирование вебхуков: проверьте доставку и парсинг событий.
- Переключение трафика: обновите переменную ENV и отслеживайте логи.
Напоследок о доставляемости
Смена провайдера — отличный повод проверить свои привычки отправки. Помните, что приём провайдером — лишь первый барьер. Доставка зависит от того, примет ли соединение принимающий почтовый провайдер (Gmail, Outlook и т. д.). Попадание во «Входящие» — последний барьер, и он определяется долгосрочной репутацией вашего домена и вовлечённостью получателей.
Не поддавайтесь искушению использовать эти API для массовых рассылок без согласия получателей. Это не только часто незаконно, но и приведёт к блокировке аккаунта, какого бы провайдера вы ни выбрали. Ограничьтесь транзакционными письмами и рассылками по согласию получателей, чтобы сохранить хорошую репутацию отправителя.
Командам, создающим AI-native приложения, стоит выбирать провайдеров с функциями для работы с агентами — MCP-серверами и файлами llms.txt, — чтобы интеграция проходила гладко. SendHQ спроектирован именно для такого сценария и даёт современным продуктовым командам нужную инфраструктуру.
Подробнее о построении надёжных почтовых систем — на https://sendhq.cc.