Виберіть наявний бренд у своєму обліковому записі
Почніть з ідентифікатора бренду в реєстрі, уже пов’язаного з вашим обліковим записом MultiTEL. Цей пошук не створює бренд і не прив’язує чужий бренд до вашого облікового запису. Поточний робочий процес клієнта перевіряє належність бренду перед запитом даних про відповідність вимогам. Якщо пошук повертає 404, перевірте вибраний обліковий запис і бренд, а не підставляйте ідентифікатор локального рядка.
Сформуйте варіанти сценаріїв використання на основі цього результату
Загальний каталог сценаріїв використання описує варіанти, які пропонує реєстр. Цей пошук для конкретного бренду надає варіанти для вибраного бренду. Збережіть кожне повернуте значення usecase і поєднайте його з назвою для відображення та описом із каталогу. Не пропонуйте всі записи загального каталогу так, ніби бренд відповідає вимогам кожного з них.
Портал очікує, що ця відповідь буде списком JSON. Якщо відповідь відсутня, має неправильний формат або містить помилку, збережіть форму клієнта й повідомте, що не вдалося завантажити дані про відповідність вимогам. Не трактуйте це без повідомлення клієнта як схвалення типового сценарію використання. Реєстр може повертати й поля, яких немає у скороченому прикладі.
Завантажте вимоги для вибраного сценарію використання
Коли клієнт вибере одне з повернутих значень сценарію використання, надішліть запит до /tcr/v2/campaignBuilder/brand/{brand_id}/usecase/{usecase} для того самого бренду. Ця відповідь надає межі для підсценаріїв використання та вимоги конкретних операторів. Використайте її, щоб зібрати зразки повідомлень, згоду й інші обов’язкові заяви. Самого списку відповідності вимогам недостатньо, щоб підготувати повний запит на реєстрацію кампанії.
Окремо перегляньте ціни для облікового запису
Поля провайдера, як-от monthlyFee, quarterlyFee або annualFee, якщо вони повертаються, описують метадані зборів провайдера. Вони не замінюють ціну для облікового запису клієнта або умови реєстрації. Поточний портал окремо зчитує роздрібні ціни кампаній і поєднує їх із даними про відповідність вимогам на екрані перевірки. Не визначайте плату для клієнта за цінами, жорстко заданими в коді старого допоміжного засобу для переліків.
Оновлюйте дані, коли змінюється бренд або сценарій використання
Під час зміни бренду відкиньте варіанти попереднього бренду й завантажте дані про відповідність вимогам для нового вибору. Перед поданням оновіть вимоги вибраного сценарію використання. Ці запити GET не подають заявку на реєстрацію, не активують кампанію й не призначають номери.
Запит
Використовуйте ввімкнений обліковий запис API через HTTPS з дозволеної вихідної IP-адреси. Поточний маршрут підтримує політику автентифікації облікового запису, зокрема автентифікацію Basic і ввімкнені облікові записи API з автентифікацією за токеном пред’явника. Не використовуйте облікові дані провайдера.
Запит GET з ідентифікатором бренду в шляху URL. Тіло запиту не потрібне.
curl --fail-with-body --silent --show-error \
--user "$API_USER:$API_PASSWORD" \
"https://api.multitel.net/tcr/v2/campaignBuilder/brand/$BRAND_ID"| Назва | Тип | Обов’язковий | Опис |
|---|---|---|---|
brand_id | рядок | Так | Ідентифікатор бренду в реєстрі, пов’язаний із вашим автентифікованим обліковим записом MultiTEL. Використовуйте ідентифікатор бренду, а не ідентифікатор рядка локальної бази даних, ідентифікатор кампанії чи податковий номер підприємства. Закодуйте його як один сегмент шляху URL. |
Відповідь
Поточний маршрут TCR повертає тіло JSON реєстру безпосередньо та зберігає його статус HTTP. Він не додає застарілу оболонку v3 status/response. Скорочений вигаданий приклад не є реальним результатом перевірки відповідності вимогам. Перед використанням відповіді перевірте статус HTTP та очікувану структуру JSON. Поточний портал очікує список записів про відповідність вимогам, кожен із яких визначає usecase. Він поєднує ці записи з каталогом usecase, щоб отримати назви для відображення, а роздрібні ціни зчитує окремо. Можуть бути присутні додаткові поля провайдера.
Ілюстративна структура відповіді; це не реальні дані облікового запису й не актуальна цінова пропозиція.
[
{
"usecase": "2FA"
}
]Помилки
- 401: Не вдалося автентифікувати обліковий запис. Перевірте облікові дані API, чи ввімкнено обліковий запис, і застосовні обмеження вихідної IP-адреси.
- 404: Бренд не пов’язаний з автентифікованим обліковим записом або провайдер не може знайти запитаний бренд чи вибраний варіант. Локальна відмова через перевірку належності повертається до надсилання запиту провайдеру.
- Інші помилки реєстру: Статус HTTP і тіло відповіді, отримані від реєстру, зберігаються. Недійсний або недоступний сценарій використання не означає успішно отриманий порожній набір вимог.
- 429: Досягнуто ліміту запитів облікового запису або спільного ліміту провайдера. Дотримуйтеся вказівки Retry-After.
- 502/503: Збій транспорту або недоступність провайдера чи обмежувача частоти запитів. Збережіть форму й повторіть спробу, збільшуючи інтервали між спробами.
Доступність і побічні ефекти
- Перевірений запит GET перевіряє належність наявного бренду, звертається до реєстру та створює записи аудиту запитів. Він не створює бренд або кампанію й не стягує плату за реєстрацію.
- Метадані зборів провайдера не є роздрібною ціновою пропозицією для клієнта MultiTEL. Портал окремо перевіряє ціни для облікового запису перед подальшим запитом на реєстрацію.
- Відповідність вимогам і самі вимоги можуть змінюватися. Перед поданням оновіть їх для вибраного бренду та сценарію використання. Успішний пошук не є схваленням кампанії, призначенням номера або дозволом почати надсилати повідомлення.