SMPP или HTTP API для SMS: что выбрать для интеграции

Короткий ответ: HTTP API обычно удобнее для быстрого запуска и умеренного транзакционного потока, а SMPP — для постоянной высокой нагрузки, двустороннего обмена и тонкого управления очередью. Протокол сам по себе не гарантирует доставку: результат зависит также от маршрутов, ограничений оператора, обработки DLR и архитектуры вашего приложения.

Если нагрузка неоднородна, практичным решением может быть не выбор «раз и навсегда», а единый внутренний сервис уведомлений с HTTP-интерфейсом для бизнес-систем и SMPP-подключением к SMS-платформе.

SMPP и HTTP API: в чём принципиальная разница

SMPP поддерживает длительную TCP-сессию между приложением и SMSC или SMS-шлюзом. Клиент привязывается как transmitter, receiver или transceiver, отправляет PDU и получает ответы и отчёты доставки в том же соединении.

HTTP API строится на отдельных HTTP-запросах. Приложение передаёт сообщение через POST, получает идентификатор, а статус узнаёт через webhook или отдельный запрос. Такой интерфейс проще встроить в веб-приложение и корпоративную шину.

Критерий	SMPP	HTTP API
Тип соединения	Длительная сессия	Запрос–ответ
Типичная нагрузка	Постоянная, высокая	Низкая, средняя или всплесками
Двусторонний обмен	Встроен в протокол	Через webhook или polling
Сложность клиента	Выше	Ниже
Управление потоком	Window size, bind, throttling	Лимиты запросов, очереди, коды HTTP
Отладка	Нужны SMPP-инструменты	Привычные HTTP-инструменты

Публичная спецификация SMPP 3.4 описывает команды, форматы PDU и режимы сессии. Для HTTP важно согласовать не только URL, но и контракт API: поля, аутентификацию, идемпотентность, ошибки и версионирование.

Когда выбирать SMPP

SMPP имеет смысл, когда SMS — отдельный производственный поток, а не вспомогательная функция:

• сообщения идут непрерывно и большими пакетами;
• важна управляемая конкурентность отправки через окно неподтверждённых PDU;
• приложение принимает входящие сообщения или DLR в той же сессии;
• команда умеет поддерживать reconnect, enquire link, повторный bind и разбор кодов ошибок;
• производительность нужно регулировать отдельно по соединению и маршруту.

Пропускная способность определяется не только числом сессий. Слишком большое окно может увеличить очередь и время до фактической доставки, а слишком маленькое — не использовать доступный лимит. Нагрузочный тест должен измерять полный путь: постановка в очередь, принятие платформой, DLR и задержку до абонента.

Когда HTTP API рациональнее

HTTP API обычно выигрывает, если нужно быстро подключить интернет-магазин, CRM, ERP или микросервис. Для клиента доступны стандартные библиотеки, TLS, балансировщики, прокси и инструменты наблюдаемости.

Выбирайте HTTP API, если:

1. поток умеренный или возникает короткими всплесками;
2. разработчики не поддерживают SMPP-клиенты;
3. уведомления отправляют несколько независимых сервисов;
4. нужен простой синхронный ответ о приёме сообщения;
5. статусы удобно получать через подписанный webhook.

Для интеграции бизнес-систем полезно начать с готового сценария — например, подключения SMS к 1С и Битрикс24. Если готового коннектора нет, выделите адаптер, чтобы формат провайдера не проникал во все приложения.

Семантика доставки важнее транспорта

Независимо от протокола разделяйте как минимум четыре состояния:

1. запрос создан бизнес-системой;
2. сообщение принято вашим шлюзом;
3. сообщение принято SMS-платформой или оператором;
4. получен конечный отчёт о доставке либо об ошибке.

Идентификаторы на каждом участке следует связать корреляционным ID. Ответ submit_sm_resp или HTTP 202 Accepted подтверждает приём запроса, но не доставку на телефон. Для одноразовых кодов дополнительно измеряйте долю доставок до истечения TTL.

В руководстве по выбору SMS-платформы разобраны маршруты, отчёты и SLA, а базовые A2P-сценарии объяснены в статье что такое A2P SMS.

Повторы без дублей

Сетевой таймаут создаёт неопределённость: сервер мог принять сообщение, хотя клиент не увидел ответ. Без защиты автоматический retry отправит второе SMS.

Для обоих протоколов нужен прикладной механизм:

• создавайте стабильный ключ идемпотентности до первой попытки;
• храните связь ключа с ID сообщения у провайдера;
• повторяйте только временные ошибки;
• применяйте exponential backoff с jitter;
• ограничивайте срок повторов бизнес-ценностью сообщения;
• отправляйте неразрешимые ошибки в отдельную очередь для разбора.

В SMPP учитывайте sequence number только в пределах конкретной сессии: это не долгоживущий бизнес-идентификатор. В HTTP API уточните, поддерживает ли провайдер идемпотентность на своей стороне.

Безопасность подключения

Для HTTP API базовый минимум — TLS, короткоживущие или регулярно ротируемые ключи, ограничение по IP там, где оно применимо, и подпись webhook. Не записывайте номера телефонов, тексты сообщений и секреты целиком в общие логи.

Для SMPP согласуйте защищённый транспорт или закрытый сетевой контур, отдельные учётные данные на среду и IP allowlist. Секрет не должен находиться в исходном коде. Процедуру отзыва ключа или пароля следует проверить до промышленного запуска.

Чек-лист пилота

• Опишите профиль: средний поток, пик, длительность пика и размер пакета.
• Проверьте ограничение скорости и поведение при throttling.
• Смоделируйте разрыв соединения и недоступность webhook.
• Сопоставьте статусы DLR с внутренней моделью.
• Проверьте идемпотентность и отсутствие дублей после таймаута.
• Измерьте p95/p99 принятия и получения конечного статуса.
• Убедитесь, что секреты ротируются, а персональные данные маскируются.
• Зафиксируйте ответственных и порядок эскалации.

Как принять решение

Не выбирайте SMPP только из-за слова «высоконагруженный» и HTTP только из-за простоты примера в документации. Возьмите реальный суточный профиль, требования к задержке, компетенции команды и стоимость сопровождения.

Для большинства прикладных систем хорошая граница ответственности выглядит так: бизнес-приложения вызывают внутренний HTTP API, сервис уведомлений управляет шаблонами, дедупликацией и статусами, а наружный адаптер подключается к SMS-платформе QuickTel по подходящему протоколу. Такой слой можно развивать вместе с интеграционной API-архитектурой, не переписывая все источники сообщений.

CTA: подготовьте профиль нагрузки и список обязательных статусов. Команда «Лоджик Телеком» поможет обсудить схему подключения, а специалисты QuickTel — подобрать SMS-интерфейс под ваш сценарий.