Синхронізація inbound opt-out між multi-tenant акаунтами

Синхронізація inbound opt-out між multi-tenant акаунтами.

Архітектурний огляд ізоляції та баз блокування

У платформі IOSOR обробка вхідних команд на відмову вимагає чіткого розмежування орендарів та виконання нормативних вимог. Коли кінцевий абонент надсилає ключове слово STOP, ядро маршрутизації перехоплює пакет до його передачі у робочу область субрахунку. Такий підхід гарантує перевагу юридичних правил над налаштуваннями конкретної кампанії. Платформа працює за моделлю передплати з порогом у 20 USD, що гарантує платоспроможність вхідного трафіку.

Аналіз ключових слів та маршрутизація JIT

Обробка вхідного трафіку починається на прикордонному шлюзі, куди надходять повідомлення у форматі E.164. Модуль аналізу сканує текст на наявність стандартних команд стоп. Номери виділяються динамічно за технологією JIT, що виключає створення застарілих або статичних резервів. При виявленні слова STOP шлюз негайно надсилає webhook-повідомлення у робочу область субрахунку та оновлює системний реєстр.

Глобальні заборони та ізольовані параметри субрахунків

Поєднання загальних нормативних вимог та автономії клієнтів реалізується через багаторівневу базу даних. IOSOR розділяє дані блокувань на локальні та загальносистемні домени. Якщо корпоративний клієнт використовує кілька субрахунків для різних проєктів, відмова в одному з них може або поширюватися на всю систему, або залишатися всередині конкретної кампанії. Це запобігає змішуванню списків відписок.

Синхронизація через вебхуки та події платформи

Під час оновлення статусу відписки зовнішні системи отримують миттєві сповіщення через вебхуки з мінімальною затримкою. Пакет даних містить номер телефону, мітку часу, збіг ключового слова та ідентифікатор орендаря. Для уникнення конфліктів під час пікових навантажень IOSOR використовує розподілене блокування ключів. Це забезпечує миттєву відмову в усіх вузлах кластера.

Управління комплаєнсом та технічна документація

Підтримання високих стандартів надійності вимагає неухильного дотримання мережевих регламентів та правил маршрутизації. Адміністраторам варто звернутися до офіційної документації для правильного налаштування середовища та обробки вхідного потоку. Ознайомтеся з цими посиланнями для детального вивчення параметрів та лімітів.

Пов'язані матеріали: політика ключових слів STOP і HELP · гід двостороннього inbox · Огляд вхідного обсягу: навантаження ключовими словами, що виснажує гаманець.

Почніть з IOSOR

Посадіть STOP на DID орендаря A. Доведіть, що орендар B на тій самій платформі все ще може слати на цей MSISDN. Синхронізуйте відмову лише за номерами орендаря A. Експортуйте id орендаря поруч із рядком suppression. Це синхронізація STOP у межах орендаря, не запис списку на один DID і не перевірка підпису.

Підсумок IOSOR

STOP належить орендарю, не спільному inbox платформи.

Робіть: ізолюйте список, потім синхронізуйте всередині цього орендаря. Не робіть: копіювати один STOP на всі субрахунки, що ділять хост.