Читання вимог до кампанії для бренду

Тримайте бренд і варіант використання разом

Використовуйте ідентифікатор бренду з вашого облікового запису та значення варіанта використання, повернуте списком кваліфікації цього самого бренду. Робочий процес клієнта перевіряє право власності перед запитом до провайдера. Переконайтеся, що поле usecase поверненого об'єкта відповідає вибраному значенню. Пошук для одного бренду або варіанта використання не встановлює вимог для іншого.

Прочитайте поточні вимоги

Застосовуйте вимоги вибраних операторів разом

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

Вимоги описують, що потрібно надати; вони не доводять, що процес отримання згоди клієнта або вміст кампанії відповідає цим вимогам. Збирайте правдиві, репрезентативні зразки та декларації. Не вмикайте декларації автоматично лише для того, щоб форма пройшла перевірку.

Підготуйте зразки та відповіді для абонентів

Поточна форма кампанії використовує поля від sample1 до sample5 для зразків повідомлень. Якщо вимоги неможливо виконати в межах доступної форми, зупиніться та вирішіть питання вибору зі службою підтримки. Для увімкненої декларації щодо абонентів надайте відповідні ключові слова та текст відповіді: optinKeywords/optinMessage, optoutKeywords/optoutMessage та helpKeywords/helpMessage. Зразки мають відповідати вибраному варіанту використання та фактичним повідомленням клієнта.

Перевірте перед будь-яким запитом на реєстрацію

Оновлюйте вимоги, коли змінюється бренд, варіант використання або вибір операторів. Перед створенням портал повторно перевіряє вибраний варіант використання, кількість підваріантів використання, прийнятність операторів, зразки та декларації. Окремо перегляньте тарифи облікового запису та умови реєстрації. Цей GET не реєструє та не схвалює кампанію, не передає її оператору обміну повідомленнями та не призначає номер телефону. Створення та надання ресурсів є окремими операціями.

Обробка невдалого пошуку вимог

Якщо запит завершується помилкою, повертає неочікуваний JSON або не відповідає вибраному варіанту використання, залишайте форму незавершеною та дозвольте клієнту повторити спробу після усунення помилки. Не замінюйте недоступні вимоги порожнім об'єктом і не вважайте, що відсутність даних означає відсутність вимог. Дотримуйтеся заголовка Retry-After та використовуйте експоненційну затримку в разі обмежень частоти запитів і збоїв доступності.

Запит

Використовуйте увімкнений обліковий запис API через HTTPS з дозволеної IP-адреси джерела. Поточний маршрут підтримує політику автентифікації облікового запису, зокрема автентифікацію Basic та увімкнені облікові записи API з bearer-токенами. Не використовуйте облікові дані провайдера.

GET з ідентифікатором бренду та вибраним значенням варіанта використання в шляху URL. Тіло запиту не потрібне.

curl --fail-with-body --silent --show-error \
  --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/campaignBuilder/brand/$BRAND_ID/usecase/$USECASE"

Відповідь

Поточний маршрут TCR повертає тіло JSON реєстру безпосередньо та зберігає його HTTP-статус. Він не додає застарілу обгортку status/response версії v3. Скорочений вигаданий приклад не є реальним результатом кваліфікації. Перед використанням перевірте HTTP-статус і очікувану структуру JSON. Портал очікує об'єкт, поле usecase якого відповідає вибраному варіанту використання. Вимоги операторів містяться в mnoMetadata з ключами за ідентифікатором оператора. Ідентифікатор оператора та вимоги в прикладі є вигаданими. Можуть повертатися й інші поля провайдера.

Ілюстративна структура відповіді; не реальні дані облікового запису та не актуальна цінова пропозиція.

{
  "usecase": "2FA",
  "minSubUsecases": 0,
  "maxSubUsecases": 0,
  "mnoMetadata": {
    "12345": {
      "mnoSupport": true,
      "qualify": true,
      "minMsgSamples": 1,
      "reqSubscriberOptin": true,
      "reqSubscriberOptout": true,
      "reqSubscriberHelp": true,
      "noEmbeddedLink": false,
      "noEmbeddedPhone": false
    }
  }
}

Помилки

• 401: Автентифікація облікового запису не вдалася. Перевірте облікові дані API, стан увімкнення та застосовні обмеження за IP-адресою джерела.
• 404: Бренд не пов'язаний з автентифікованим обліковим записом, або провайдер не може знайти запитаний бренд чи вибір. Локальна відмова через право власності повертається до запиту до провайдера.
• Інші помилки реєстру: HTTP-статус і тіло відповіді вищого рівня зберігаються. Недійсний або недоступний варіант використання не є успішним порожнім набором вимог.
• 429: Досягнуто ліміту запитів облікового запису або спільного ліміту провайдера. Дотримуйтеся заголовка Retry-After.
• 502/503: Збій доступності транспорту, провайдера або обмежувача частоти запитів. Збережіть форму та повторіть спробу з експоненційною затримкою.

Доступність і побічні ефекти

• Перевірений GET перевіряє наявне право власності на бренд, звертається до реєстру та записує аудиторські записи запитів. Він не створює бренд або кампанію та не стягує реєстраційний збір.
• Метадані зборів провайдера не є роздрібною ціновою пропозицією MultiTEL для клієнта. Портал окремо переглядає тарифи облікового запису перед подальшим запитом на реєстрацію.
• Кваліфікація та вимоги можуть змінюватися. Оновлюйте їх для вибраного бренду та варіанта використання перед поданням. Успішний пошук не є схваленням кампанії, призначенням номера чи дозволом розпочати розсилку повідомлень.