Email API: что это и как выбрать под адресный B2B-аутрич

Email API нужен, когда письма должен отправлять ваш софт, а не человек в интерфейсе сервиса рассылок. Для адресного B2B-аутрича это типичная ситуация: письма уходят из CRM или собственного пайплайна, статусы доставки и ответы должны возвращаться обратно в карточку контакта. Разберём, что такое Email API, какие бывают и по каким критериям выбирать, чтобы не переплатить за ненужный функционал ESP.

Что такое Email API и чем он отличается от ESP

Email API — это программный интерфейс, через который ваше приложение отправляет письма и получает данные об их судьбе. Вместо того чтобы заходить в интерфейс сервиса, загружать список и нажимать «Отправить», ваш код делает HTTP-запрос: адрес получателя, тема, тело письма, заголовки. Провайдер принимает запрос, ставит письмо в очередь, доставляет и сообщает о событиях — доставлено, открыто, отклонено, помечено как спам.

ESP (сервис email-рассылок) — это надстройка над той же инфраструктурой: визуальный редактор, управление списками подписчиков, готовая аналитика, шаблоны. ESP рассчитан на маркетолога, который работает руками. Email API рассчитан на разработчика, который встраивает отправку в продукт или процесс.

Для адресного B2B-аутрича граница проходит так: если письма конкретным ЛПР уходят из вашей CRM или самописного пайплайна, где живут карточки компаний и контактов, вам нужен именно API-слой. Тащить базу юрлиц в интерфейс ESP, заточенный под подписчиков рассылки, — значит терять контекст сделки и дублировать данные.

Какие задачи Email API решает в адресном аутриче

В холодном B2B-аутриче объёмы небольшие — десятки и сотни писем в день, а не миллионы. Зато каждое письмо адресное: конкретному человеку в конкретной компании, с персонализацией под его роль и контекст. Поэтому требования к API смещаются с «пропускной способности» на «наблюдаемость».

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

Вторая задача — двусторонняя связь с CRM. Отправка письма создаёт активность в карточке контакта; ответ получателя должен туда же и вернуться. Значит, помимо API отправки нужен либо приём входящих (inbound parsing, IMAP-интеграция), либо готовый коннектор к вашей CRM. Без этого SDR будет вести переписку в почтовом клиенте, а CRM останется пустой.

Третья задача — управление последовательностями. Холодный аутрич — это цепочка из 2–4 касаний с интервалами и остановкой по ответу. Часть провайдеров отдаёт это на откуп вашему коду, часть предлагает API последовательностей. Оба варианта рабочие, но логику «стоп при ответе» проверяйте особенно тщательно: письмо после полученного ответа — верный способ испортить впечатление.

Критерии выбора: на что смотреть в документации

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

• Вебхуки по событиям: delivered, bounce с разделением на hard/soft, open, click, complaint, unsubscribe. Проверьте, есть ли ретраи при недоступности вашего endpoint.
• Отправка с вашего домена: поддержка SPF, DKIM, DMARC, кастомный return-path. Для B2B-аутрича письма с чужого домена — почти гарантированный спам-фолдер.
• Выделенный IP или качественный shared-пул: при малых объёмах выделенный IP не прогреется, поэтому важна репутация общего пула провайдера.
• Идемпотентность и повторная отправка: что произойдёт, если ваш код отправит запрос дважды из-за таймаута.
• Лимиты и троттлинг: сколько запросов в секунду, как API сообщает о превышении, можно ли задать скорость отправки на свой домен.
• Приём входящих: inbound webhook или IMAP-доступ, чтобы ответы попадали в CRM.
• Логи и поиск: возможность найти конкретное письмо по получателю за последние 30 дней прямо через API.
• Тарификация: за письмо, за пачку, за подписку. При объёмах аутрича в 1–3 тысячи писем в месяц тарифы «от 50 000 писем» — переплата.

SMTP-релей или HTTP API: что взять

Почти все провайдеры дают два способа отправки: классический SMTP-релей и HTTP API. SMTP проще подключить к готовому софту — почти любой почтовый клиент, CRM или скрипт умеет отправлять через SMTP с логином и паролем. HTTP API удобнее для собственного кода: структурированные ошибки, метаданные, теги, шаблоны на стороне провайдера.

Практическое правило: если вы встраиваете отправку в самописный пайплайн — берите HTTP API, ошибки будут понятнее и обработка событий чище. Если подключаете готовую CRM или инструмент, который умеет только SMTP, — берите SMTP-релей, но убедитесь, что события доставки всё равно доступны через вебхуки или API статистики, иначе вы останетесь слепыми.

Отдельный сценарий B2B-аутрича — отправка через собственные почтовые ящики (корпоративный Google Workspace, Microsoft 365 или свой почтовый сервер). Письмо от реального ящика сотрудника выглядит естественнее и лучше проходит фильтры, чем письмо через маркетинговую инфраструктуру. В этом случае Email API провайдера заменяется API почтовой платформы или IMAP/SMTP-доступом к ящикам, а задача трекинга ложится на вашу систему — так устроена и отправка в LDM.

Частые ошибки при выборе и внедрении

Главная ошибка — выбирать API по цене за тысячу писем, когда ваш объём — сотни адресных писем в месяц. Разница в 20% стоимости на таких объёмах — копейки, а разница в качестве вебхуков и репутации пула — это проценты доставляемости во «Входящие», то есть напрямую ответы и сделки.

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

Третья ошибка — игнорировать обработку баунсов. Если ваш код продолжает слать письма на адреса после хард-баунса, репутация домена деградирует за считанные недели. Правило простое: hard bounce — адрес в стоп-лист немедленно и навсегда, soft bounce — пауза и ретрай с ограничением попыток.

Четвёртая — тестировать на проде. Любой нормальный провайдер даёт песочницу или тестовый режим. Прогоните через него сценарии: успешная доставка, hard bounce, жалоба на спам, недоступный вебхук-endpoint. Час тестов сэкономит недели разбора инцидентов.

Как это устроено в LDM и чек-лист выбора

В LDM мы прошли этот путь на своей платформе: отправка идёт через реальные почтовые ящики с контролем скорости и прогрева, все события — доставка, баунсы, открытия, ответы — возвращаются в CRM и привязываются к карточке компании и контакта. Ответ ЛПР автоматически останавливает цепочку и создаёт диалог для SDR. Именно такой замкнутый контур мы советуем строить, что бы вы ни выбрали в качестве транспорта.

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

• Сценарий описан: объёмы, источник отправки, получатели событий.
• Домены разнесены: аутрич отдельно от транзакционных и маркетинговых писем.
• SPF, DKIM, DMARC настроены и проверены на тестовых письмах.
• Вебхуки принимаются, все типы событий пишутся в CRM.
• Обработка баунсов и жалоб автоматическая, стоп-лист общий для всех кампаний.
• Ответы получателей попадают в CRM и останавливают цепочку.
• Тариф соответствует реальному объёму, а не маркетинговой упаковке.

Вопросы и ответы