Разработчици

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 може да означава, че регистърът е приел операцията, но локалното трайно съхраняване или таксуването е неуспешно. Запазете идентификатора на заявката, прегледайте текущите записи и изяснете състоянието със съдействието на поддръжката, преди да използвате нов ключ. Не приемайте, че грешката означава, че няма поръчка.