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

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

Импорт существующего результата проверки

Свяжите существующий результат поддерживаемого поставщика с вашим брендом.

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

Используйте бренд для обмена сообщениями, принадлежащий вашей учётной записи

Используйте активную учётную запись API через HTTPS с разрешённого исходного IP-адреса. Поддерживается аутентификация Basic и Bearer. Идентификатор бренда должен принадлежать этой учётной записи. Обеспечьте конфиденциальность токенов поставщика, идентификационных данных бренда и полученных отчётов.

Используйте существующий результат поставщика

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

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

Подготовьте импорт

Поля импорта внешней проверки
ПолеЗначение
evpIdИдентификатор поддерживаемого поставщика, 1–10 символов.
vettingIdФактический идентификатор транзакции проверки у поставщика, не более 255 символов. Не подставляйте вместо него идентификатор бренда и не придумывайте идентификатор.
vettingTokenТокен подтверждения, если он требуется поставщиком, не более 65535 символов. Храните его в секрете и не передавайте, если поставщик его не требует.

Создайте vetting-import.json, используя фактические значения поставщика. Не отправляйте поля оценки, статуса или временной метки, предназначенные только для ответа, в расчёте на то, что они могут изменить результат.

Импортируйте результат один раз

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

Учитывайте существующие начисления

Этот прокси-сервис не регистрирует вновь импортированный результат как новый платный заказ. Это не отменяет ранее заказанную проверку: если для того же vettingId уже существует заказ, ожидающий результата или списания, импорт результата ACTIVE или FAILED может привести к списанию сохранённой для этого заказа суммы сбора. В рамках этой ветви синхронизации плата за запись, по которой уже было выполнено списание, повторно не взимается.

Отслеживайте фактический результат

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

Используйте статус внешней проверки для отслеживания записи. Чтение или импорт окончательного результата может привести к списанию платы за ранее оформленный платный заказ; такая операция не обязательно исключает списание уже существующей неоплаченной суммы.

Повторяйте тот же запрос для той же операции

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

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