Разработчикам

PUT/tcr/v2/brand/{brandId}/revet

Повторная проверка бренда для обмена сообщениями

После исправления существующего профиля компании отправьте один отдельно оплачиваемый запрос на проверку идентификационных данных, затем отслеживайте результат.

На этой странице
  1. Повторная проверка исправленных идентификационных данных компании
  2. Проверьте данные бренда перед отправкой
  3. Подтвердите отдельную плату
  4. Отправьте один запрос на запланированную попытку
  5. Изучите результат и отслеживайте статус
  6. Уточните результат при неопределенном исходе
  7. Использование клиентского портала

Повторная проверка исправленных идентификационных данных компании

Используйте эту операцию, если исправленные идентификационные данные существующего бренда организации нужно проверить повторно. Сначала обновите существующий бренд, затем получите текущий статус проверки его идентификационных данных. Обычное обновление профиля не отправляет этот отдельный платный запрос. Повторная проверка не создает другой бренд и не регистрирует кампанию.

Используйте собственную активированную учетную запись 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 требует поля версии или подтверждения цены, используемые порталом. Сохранение обычного исправления данных бренда — отдельное действие, которое не отправляет запрос на повторную проверку автоматически.