Входящие MO для списков исключений: STOP на DID защищает репутацию

Входящие MO для списков исключений.

Архитектура автоматической отписки через входящие MO-сообщения

Когда конечный пользователь отвечает ключевым словом STOP, UNSUBSCRIBE или QUIT на входящее MO-сообщение на выделенном DID в формате E.164, платформа должна немедленно обработать этот сигнал. Сохранение номеров в списке исключений на уровне API предотвращает нарушение правил операторов при последующей отправке исходящего MT-трафика. Если предпринимается попытка отправить сообщение заблокированному получателю, шлюз обязан сбросить или пометить полезную нагрузку как пропущенную до начала передачи в сеть. Архитектура опирается на строгую целостность сигналов.

Маппинг входящих ключевых слов в списки исключений

Входящие MO-запросы поступают через вебхуки, содержащие номер отправителя E.164, целевой DID, timestamp и тело сообщения. Подсистема блокировки парсит стандартные ключевые слова: STOP, CANCEL, END, QUIT и OPTOUT. При обнаружении совпадения движок нормализует строку, удаляя пробелы, приводя символы к верхнему регистру и применяя регулярные выражения. Если тело содержит изолированное ключевое слово, система выполняет атомарную запись в базу данных и обновляет набор исключений в Redis. Запись содержит целевой E.164, исходный DID и временную метку.

Вебхуки, статус-коды и почему Skipped не является ошибкой

Когда запрос на исходящую отправку адресован заблокированному E.164, CPaaS-движок блокирует передачу до отправки данных вышестоящим операторским маршрутам. Платформа возвращает ответ HTTP 200 OK с телом статуса 'skipped_suppressed'. Возврат кодов 4xx или 5xx в данном случае является антипаттерном, так как он указывает на сбой инфраструктуры или ошибку формата данных, что провоцирует нежелательные повторные попытки в SDK клиента. Возвращая HTTP 200 OK со статусом 'skipped_suppressed', CPaaS позволяет клиентским сервисам корректно обрабатывать логи.

Операционные правила и контроль предоплатного баланса

Управление обработкой входящих MO и списками исключений требует надежных финансовых ограничений. CPaaS-платформы работают по строгой предоплатной схеме с порогом в USD 20 для обеспечения непрерывной обработки вебхуков и маршрутизации DID. Если баланс аккаунта опускается ниже этого минимума, входящие MO-вебхуки буферизуются в очереди до 72 часов, сохраняя критически важные сигналы отписки. При росте объемов трафика менеджеры аккаунтов оценивают входящую нагрузку для обеспечения запаса прочности.

Матрица соответствия: Обработка входящих отписок

Начните работу с IOSOR

Когда STOP садится на DID, запишите исходящий MSISDN в список suppression этого тенанта до следующего MT. Докажите, что повторная отправка отказана. Выгрузите метку MO и строку списка. Webhook 2xx без записи в список — не эта задача; чистка E.164 — другой гейт.

Связанные: IOSOR ru guide IOSOR ru guide prepaid-резерв до первого списания.

Итог IOSOR

Входящий MO на DID — запись в список, не сувенир лога.

Делайте: подавите до следующего MT. Не делайте: помечать STOP как «учли», пока MT идёт, или ждать недельной выгрузки.