Resend хорош не как «ещё один SMTP», а как быстрый слой для product email

Resend хорош не как «ещё один SMTP», а как быстрый слой для product email

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

На практике смотреть стоит не на «фичи», а на операционку:
— есть ли отдельные домены и ключи под dev/stage/prod;
— как устроены webhooks и retry при сбоях;
— можно ли быстро проверить доставку, а не гадать по логам;
— насколько легко менять шаблоны без правок в бизнес-логике.

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

Ещё один важный фильтр — миграция с другого провайдера. Сначала проверьте, как переносится suppression list, как обрабатываются bounce/complaint и есть ли возможность параллельного прогона на тестовых доменах. Если этого нет, красивый API быстро превращается в дорогую точку отказа.

Итог простой: Resend имеет смысл там, где email — продуктовая функция, а не вспомогательная скрипт-рассылка. Перед выбором проверьте не маркетинг, а маршрут письма от триггера до inbox.