Подключение внешнего сервиса рассылок в Битрикс

Штатная отправка писем через SMTP хостинга справляется с транзакционными уведомлениями, но плохо подходит для массовых маркетинговых рассылок — риск попасть в спам растёт, а инструментов аналитики открытий и переходов нет вовсе. Разберём, как подключить внешний сервис рассылок к 1С-Битрикс и разделить транзакционные и маркетинговые письма.

Зачем разделять транзакционные и маркетинговые письма

Транзакционные письма (подтверждение заказа, восстановление пароля) критичны для конкретного пользователя и должны доходить максимально надёжно и быстро. Маркетинговые рассылки (акции, дайджест новостей) идут по всей базе подписчиков и несут другой профиль риска — массовая отправка с одного IP-адреса или домена без специализированной инфраструктуры быстро портит репутацию отправителя, из-за чего начинают страдать и транзакционные письма, если они идут с того же источника.

Два способа интеграции

Первый — подключение сервиса рассылок как SMTP-релея в настройках главного модуля (Настройки → Настройки продукта → Настройки почты), при этом штатный механизм почтовых событий Битрикса продолжает работать как раньше, просто письма технически уходят через внешний сервис. Второй — прямая интеграция через REST API сервиса рассылок, дающая доступ к продвинутым возможностям вроде сегментации подписчиков и статистики открытий, недоступным при простой SMTP-отправке.

Программная отправка через REST API сервиса

<?php

use Bitrix\Main\Web\HttpClient;
use Bitrix\Main\Web\Json;

function sendToMailingService(string $email, array $variables): bool
{
    $httpClient = new HttpClient();
    $httpClient->setHeader('Authorization', 'Bearer ' . MAILING_API_KEY);
    $httpClient->setHeader('Content-Type', 'application/json');
    $httpClient->setTimeout(5);

    $response = $httpClient->post(
        'https://api.mailingservice.example/v1/send',
        Json::encode([
            'to' => $email,
            'template_id' => 'welcome_series_1',
            'variables' => $variables,
        ])
    );

    return $response !== false && $httpClient->getStatus() === 200;
}

Прямой вызов API сервиса удобен для точечной интеграции — например, добавление нового покупателя в welcome-цепочку писем сразу после первого заказа, минуя штатный механизм почтовых событий Битрикса полностью.

Синхронизация базы подписчиков

Для регулярных рассылок нужна актуальная база подписчиков на стороне сервиса — синхронизация обычно выполняется агентом, который сверяет список активных пользователей с согласием на рассылку и отправляет изменения через API сервиса. Важно синхронизировать не только добавление новых подписчиков, но и отписку — пользователь, отписавшийся через форму сайта, должен реально перестать получать письма через внешний сервис, а не только числиться отписанным в локальной базе Битрикса.

Согласие на рассылку и 152-ФЗ

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

Обработка отказов и bounce

Сервисы рассылок обычно уведомляют о недоставленных письмах (несуществующий адрес, переполненный ящик) через вебхуки — обработка этих уведомлений и деактивация невалидных адресов в локальной базе снижает нагрузку на репутацию отправителя при последующих рассылках, поскольку высокий процент bounce негативно сказывается на доставляемости всех писем сервиса.

Частые ошибки

• Транзакционные и маркетинговые письма идут через один и тот же канал. Проблемы с репутацией от массовой рассылки задевают критичные уведомления.
• Подписка на рассылку включена без явного согласия пользователя. Риск блокировки сервиса рассылок за жалобы и нарушение законодательства.
• Отписка не синхронизируется с внешним сервисом. Пользователь продолжает получать письма после отказа от рассылки.
• Вебхуки о недоставленных письмах не обрабатываются. Невалидные адреса накапливаются в базе, портя репутацию отправителя.

Итог

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