Замовте зовнішню перевірку бренду

Використовуйте бренд для обміну повідомленнями, що належить обліковому запису

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

Замовте нову зовнішню перевірку

Використовуйте POST, коли потрібно, щоб постачальник перевірок виконав нову перевірку цього бренду. Якщо ви вже маєте результат від постачальника, натомість скористайтеся імпортом. Це окрема процедура, відмінна від повторного підтвердження ідентифікаційних даних бренду.

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

Підготуйте запит до постачальника

Поля замовлення зовнішньої перевірки
Поле	Значення
evpId	Обов’язковий ідентифікатор постачальника з актуального каталогу постачальників зовнішньої перевірки, 1–10 символів.
vettingClass	Підтримуваний клас, який ви маєте намір придбати; виберіть його явно та підтвердьте його ціну.
additionalRequestPayload	Рядок, закодований у форматі JSON, із відомостями для конкретного постачальника; обов’язковий для політичної перевірки. Це рядок усередині зовнішнього об’єкта JSON, а не вкладений об’єкт. Уточніть усі обов’язкові відомості у вибраного постачальника.

Підтвердьте плату за успішний і невдалий результати

Поточні роздрібні тарифи в доларах США, переглянуті станом на 24 жовтня 2026 року. Підтвердьте актуальну суму перед оформленням реального замовлення. Достатність передплачених коштів перевіряється за ціною успішного результату; покупки мають бути дозволені.

Налаштовані тарифи зовнішньої перевірки залежно від результату
Клас	Активний результат	Невдалий результат
STANDARD	$46.12	$5.56
ENHANCED	$112.78	$6.67
POLITICAL	$73.34	$24.45
POLITICAL із запитом Express	$106.67	$24.45
AUTHPLUS	$13.89	$13.89
RCS	$83.34	$83.34

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

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

Надішліть одне перевірене замовлення

Підготуйте файл vetting-order.json з ідентифікатором постачальника, класом і всією обов’язковою додатковою інформацією. Файл містить фактичний запит, який ви маєте намір надіслати. Зберігайте його конфіденційним.

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  --request POST \
  --header 'Content-Type: application/json' \
  --header "Idempotency-Key: $IDEMPOTENCY_KEY" \
  --data-binary @vetting-order.json \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID/externalVetting"

Відстежуйте фактичний результат

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

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

Повторно надішліть той самий запланований запит

Використовуйте один Idempotency-Key для кожної запланованої операції та зберігайте точні метод, шлях, параметри запиту й байти тіла. Ключі підтримують 1–128 друкованих символів ASCII без пробілів. Дублікат запиту, який ще виконується, може повернути 409 із Retry-After. Для завершених запитів повторно повертається збережена відповідь, включно з помилками. Дотримуйтеся обмежень частоти запитів.

Після збою передавання даних може бути закешовано відповідь 502. Закешована відповідь 500 із requestId може означати, що реєстр прийняв операцію, але локальне збереження даних або нарахування чи списання плати завершилося збоєм. Збережіть ідентифікатор запиту, перегляньте поточні записи та узгодьте ситуацію зі службою підтримки, перш ніж використовувати новий ключ. Не вважайте, що помилка означає відсутність замовлення.