Повторно перевірте виправлені ідентифікаційні дані компанії
Використовуйте цю операцію, коли потрібно повторно перевірити виправлені ідентифікаційні дані наявного бренду організації. Спочатку оновіть наявний бренд, а потім перегляньте поточний статус перевірки його ідентифікаційних даних. Звичайне оновлення профілю не запускає цю окрему платну спробу. Повторна перевірка не створює іншого бренду й не реєструє кампанію.
Використовуйте власний активований обліковий запис API через HTTPS із дозволеної вихідної IP-адреси. Бренд має належати цьому обліковому запису. Зберігайте конфіденційність записів бренду: вони містять відомості про компанію та контактні дані.
Перегляньте бренд перед поданням запиту
curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
"https://api.multitel.net/tcr/v2/brand/$BRAND_ID" \
--output current-brand.jsonПереконайтеся, що повернений бренд відповідає потрібній компанії та містить виправлення. Поки первинна реєстрація очікує завершення, повторна перевірка недоступна. Реєстр може відхилити запит, якщо відомості про компанію не змінилися. За відсутності спеціальних атрибутів може знадобитися апеляція замість ще однієї перевірки ідентифікаційних даних. Для брендів індивідуальних підприємців використовується відповідний процес перевірки особи / PIN; не вважайте цю кінцеву точку його заміною.
Підтвердьте окрему плату
Наразі налаштована плата за повторну перевірку в робочому середовищі становить US$5.00 за кожну прийняту спробу, перевірено 24 жовтня 2026 року. Застосовується стандартна плата за бренд, зокрема й тоді, коли для початкового суб’єкта встановлено іншу вартість реєстрації. Покупки мають бути дозволені; перед поданням запиту на передплачених облікових записах має бути достатньо коштів.
Відповідь 202 означає, що запит прийнято для подальшої обробки, а під час прийняття ініціюється стягнення плати. Це не означає, що ідентифікаційні дані компанії підтверджено. За наступну нову спробу може стягуватися ще одна плата. Не створюйте нову спробу лише тому, що перевірка досі очікує завершення.
Подайте одну заплановану спробу
curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
--request PUT \
--header "Idempotency-Key: $IDEMPOTENCY_KEY" \
"https://api.multitel.net/tcr/v2/brand/$BRAND_ID/revet"Тіло запиту з даними профілю не потрібне: перевіряються вже збережені дані бренду. Використовуйте унікальний ключ ідемпотентності для запланованої спроби й під час повторних запитів залишайте метод, шлях, параметри запиту та тіло без жодних змін. Ключі можуть містити 1–128 друкованих символів ASCII без пробілів. Дублікат спроби, яка ще виконується, може повернути 409 із Retry-After; для завершеної спроби може бути повторно повернуто збережений результат, зокрема помилку.
Публічний API також підтримує автентифікацію Bearer для активованого облікового запису з токеном. Перевірки належності облікового запису та дозволеної вихідної IP-адреси залишаються чинними. Для збережених імітаційних брендів цей процес стягнення плати в робочому середовищі пропускається, але результат у тестовому середовищі не є перевіркою ідентифікаційних даних у робочому середовищі.
Перегляньте результат і відстежуйте його статус
| Відповідь | Значення та наступна дія |
|---|---|
| 200 | Запит виконано успішно. Перегляньте повернений бренд і повторно прочитайте його поточний запис, щоб підтвердити статус перевірки ідентифікаційних даних. |
| 202 | Прийнято, очікується подальша перевірка. Збережіть ідентифікатор бренду й перевірте його поточний статус пізніше, не подаючи ще одну платну спробу. |
| 400 | Перегляньте повернені помилки реєстру. Первинна реєстрація може очікувати завершення, профіль може бути незміненим або може діяти інше правило перевірки даних. |
| 401 / 404 | Перевірте облікові дані та дозволену IP-адресу або ідентифікатор бренду, що належить обліковому запису. |
| 402 / 503 | Перегляньте локальну помилку покупки / поповнення коштів або ціноутворення / сервісу. Не вважайте, що кожна відповідь 503 доводить відсутність запиту до вищестоящого сервісу. |
| 429 | Дотримуйтеся вказівки Retry-After і залишайте дані спроби незмінними. |
Проксі оновлює локальний запис бренду після прийнятої зміни; саме це оновлення не підтверджує остаточного результату перевірки. Компанія може залишатися непідтвердженою або очікувати перевірки. Перш ніж продовжувати налаштування кампанії, орієнтуйтеся на поточний статус бренду, а не лише на прийняття запиту за HTTP.
З’ясуйте невизначений результат
Транспортний збій може призвести до кешованої відповіді 502. Якщо вищестоящий сервіс прийняв запит, а потім стався локальний збій збереження даних або нарахування плати, може бути сформовано кешовану відповідь 500 із requestId. Збережіть цей ідентифікатор і разом зі службою підтримки звірте поточний стан бренду та нарахувань. Створення іншого ключа може призвести до окремо оплачуваної спроби; не повторюйте запит із новим ключем навмання.
Використання клієнтського порталу
Портал пропонує повторну перевірку організації в робочому середовищі зі статусом UNVERIFIED після перегляду поточного профілю та плати. Він перевіряє, що профіль і ціна не змінилися, та не допускає повторного прийняття подання з тими самими поточними даними. Ця дія порталу недоступна для брендів у тестовому середовищі та брендів індивідуальних підприємців.
Ці запобіжні заходи порталу є додатковими перевірками робочого процесу. Клієнти, що безпосередньо використовують API, мають самостійно виконувати перевірку й не повинні припускати, що API вимагає поля версії або підтвердження ціни, які використовує портал. Збереження звичайного виправлення даних бренду є окремою дією й не подає запит на повторну перевірку автоматично.