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

Виберіть бренд, який перевіряєте

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

Відстежуйте наявну перевірку

Зберігайте vettingId, evpId, vettingClass і vettingStatus за їх наявності. Поточний механізм синхронізації розглядає PENDING і UNSCORE як результати, що ще очікують на подальшу перевірку, а ACTIVE і FAILED — як остаточні результати для проведення розрахунків. Перш ніж вирішувати, чи потрібні подальші дії, прочитайте повернуті відомості. Сам по собі порожній список не доводить, що попереднє подання не надійшло до реєстру.

З’ясуйте нарахування за попереднє замовлення

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

Повторіть читання даних без нового замовлення

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

Розділяйте етапи реєстрації

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

Запит

Використовуйте обліковий запис з увімкненим доступом до API та підключайтеся через HTTPS з дозволеної вихідної IP-адреси. Використовуйте облікові дані свого облікового запису, а не реєстру. Бренд має бути пов’язаний з автентифікованим обліковим записом.

Надішліть запит GET з ідентифікатором бренду в шляху та обов’язковим фільтром запиту vettingStatus. Переглянута схема визначає масив статусів; у цьому прикладі запитується одне значення ACTIVE. Цей посібник не встановлює способу кодування кількох значень і не підтверджує, що постачальник приймає запити без фільтра. Тіло запиту не потрібне.

curl --fail-with-body --silent --show-error \
  --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID/externalVetting?vettingStatus=ACTIVE"

Відповідь

Поточний маршрут зберігає статус HTTP і тіло відповіді реєстру замість використання застарілої обгортки відповіді v3. Скорочений вигаданий масив ілюструє поля, які використовує локальний механізм синхронізації; це не зафіксована відповідь реєстру й не гарантовано повна схема. Перш ніж читати записи, перевірте статус HTTP і JSON. Зберігайте кожен vettingId разом із вибраним брендом.

Приклад структури відповіді; це не фактичні дані облікового запису й не поточна цінова пропозиція.

[
  {
    "vettingId": "example-vetting-id",
    "evpId": "example-review-provider",
    "vettingClass": "STANDARD",
    "vettingStatus": "ACTIVE"
  }
]

Помилки

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

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

• Цей запит GET не створює нового замовлення на перевірку. Він отримує результати з реєстру, створює записи аудиту запитів і синхронізує збережені результати.
• Читання завершеного результату може призвести до розрахунку за раніше розміщеним платним замовленням на перевірку. За невдалу перевірку може стягуватися відповідна плата. Переглядайте ціну та умови під час замовлення; цей запит на читання не є ціновою пропозицією.
• Щойно виявлений запис, імпортований цим запитом GET, не класифікується автоматично як нове платне замовлення.
• Успішний результат перевірки або статус ACTIVE не означає схвалення кампанії, призначення телефонного номера чи дозволу надсилати повідомлення.