Базу наружу не отдаёте
CDP — мастер-система: профили, сегменты и согласия живут у вас. Нужен канал отправки, а не чужой UI рассылок
Решения
SMTP для
своей CDP
Сегменты и HTML уже у вас — встройте пакетный транспорт без своей MTA
и без SES-чанков по 50 писем
Зачем внешний транспорт в CDP
Транспорт в ваш модуль
API и SMTP встраиваются в ваш сервис. Данные клиентов остаются в периметре CDP
SES-like API и микропакеты
Типичный облачный SES-совместимый API: до 50 писем или 500 получателей на запрос — плюс очередь и квоты на скорость
Пакет под массовую волну
Один запрос — до 500 000 адресов и до 400 Мб. Burst без сотен тысяч HTTP-вызовов
Своя MTA дороже ядра продукта
Очереди, репутация IP, баунсы и антиспам — отдельная команда и железо, не профиль CDP
Доставляемость на нашей стороне
Сендеры, стоп-листы, валидация и разбор недоставок — у SaM oTPravil. Вы пишете интеграцию один раз
Контракт для разработчика
Пакетный метод
До 500 000 адресов и до 400 Мб в одном запросе — массовая волна без своей почтовой инфры
Свои ID писем
X-Track-ID / externalId из вашей БД — связь с логом CDP и поддержкой без чужого message-id
Статусы по webhook
delivered, bounce, spam, open, click — обратно в CDP без опроса API
Стоп-листы по рубрикам
Проверка на лету; для транзакций проверку по стопам можно отключить на ключе
Валидация до отправки
Отсев невалидных и жалобщиков по накопленным стоп-листам — меньше ударов по репутации
Нативная отписка
List-Unsubscribe в заголовке и отчёт об отписавшихся за период — без ручного разбора ЛК
SES-like API vs пакет SaM
Типичный SES API
Микропакет: до 50 писем или 500 получателей на запрос. Нужны чанкинг, очередь, rate limit и рост квот на burst
Пакетный API SaM
Крупные чанки под волну, SMTP на триггеры, retry на стороне сервиса. Очередь у вас — только перед API
Своя MTA
Полный контроль ценой железа, антиспама и 24/7. Имеет смысл при отдельной команде — иначе внешний транспорт быстрее
Две модели персонализации
Пакет + Jinja
Шаблон и переменные на стороне провайдера. Один пакет — персональные письма по сегменту из CDP
Готовый HTML one-to-one
HTML уже собран у вас (рекомендации, блоки). Шлёте письмо за письмом или пачками one-to-one — без чужого шаблонизатора
Модуль рассылок внутри CRM или SaaS?
Если письма шлют клиенты вашей платформы (multi-tenant, выделенные IP) — смотрите лендинг SMTP для SaaS.
Здесь — своя CDP и своя база, без отдачи мастер-системы
Доказательства рядом
Как подключаемся
-
Схема под вашу CDP Массовые vs триггеры, пакет + Jinja или готовый HTML, ключи и политика стоп-листов
-
Песочница Тестовый аккаунт, webhooks, X-Track-ID — без риска для продакшена
-
Боевой запуск Домены, сендеры, прогрев. Retry на нашей стороне; у вас — очередь перед API
Частые вопросы
Это замена CDP?
Нет. CDP остаётся мастер-системой: сегменты, согласия и HTML — у вас. Мы — почтовый транспорт: пакетный API, SMTP, статусы и доставляемость.
Чем это отличается от SMTP для SaaS?
SaaS — модуль рассылок внутри продукта, где письма шлют клиенты платформы (часто multi-tenant и выделенные IP). Эта страница — для своей CDP или своего сервиса рассылок, когда базу наружу не отдаёте.
У SES тоже есть bulk — зачем менять?
Bulk в SES-like API обычно микропакет: десятки писем или сотни получателей на запрос плюс квоты на скорость. У нас — крупные пакеты под burst и контракт (ID, webhooks, стоп-листы), заточенный под встраивание в CDP.
Как связать письмо с записью в нашей БД?
Передаёте свой идентификатор в X-Track-ID (или externalId) при отправке — дальше ищете по нему в логах и в событиях webhook.
Можно ли отключить стоп-листы для транзакций?
Да. На отдельном API-ключе настраивается, по каким стоп-листам проверять получателя. Маркетинг и OTP/чеки не мешают друг другу.
Для вендора CDP: как делить клиентов платформы?
Типовая схема: один тенант (клиент вашей CDP) = одна рассылка / API-ключ у нас. Домены, лимиты и статистика не смешиваются между арендаторами.
Где инфраструктура?
Серверы и поддержка в российском контуре. Для закупки есть материалы по 152-ФЗ.