<b>Resend: когда нужен email API без боли, и где чаще всего ошибаются</b>

<b>Resend: когда нужен email API без боли, и где чаще всего ошибаются</b>

Если проекту нужен транзакционный email, Resend обычно берут не за «ещё один SMTP», а за нормальный DX: API, вебхуки, шаблоны, домены, инвайты для команды. Для веб-проекта это часто быстрее, чем собирать рассылку на голом почтовом сервере.

За неделю в репах: почти всегда ломаются не письма, а базовая обвязка вокруг них.
— не настроен SPF/DKIM/DMARC
— отправка идёт из тестового домена
— нет отдельного адреса для bounce/complaints
— webhook-обработчик не идемпотентен
— письмо собрано без fallback на plain text

Есть наблюдение которое стоит проверить: email API окупается только там, где у вас есть события, а не «массовая рассылка ради рассылки». Подтверждение почты, сброс пароля, уведомления, чеки, алерты — вот его зона. Если нужен маркетинг-стек, лучше сразу разделять инфраструктуру и репутацию домена.

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

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