Izstrādātājiem

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

Importējiet esošu pārbaudes rezultātu

Saistiet atbalstīta pakalpojumu sniedzēja esošu rezultātu ar savu zīmolu.

Šajā lapā
  1. Izmantojiet kontam piederošu ziņapmaiņas zīmolu
  2. Izmantojiet esošu pakalpojumu sniedzēja rezultātu
  3. Sagatavojiet importēšanu
  4. Importējiet rezultātu vienu reizi
  5. Izprotiet esošās maksas
  6. Sekojiet faktiskajam iznākumam
  7. Atkārtojiet to pašu iecerēto pieprasījumu

Izmantojiet kontam piederošu ziņapmaiņas zīmolu

Izmantojiet iespējotu API kontu, savienojoties ar HTTPS no atļautas avota IP adreses. Tiek atbalstīta Basic un Bearer autentifikācija. Zīmola identifikatoram jāatbilst šim kontam piederošam zīmolam. Saglabājiet pakalpojumu sniedzēja pilnvaras, zīmola identitātes datus un saņemtos pārskatus konfidenciālus.

Izmantojiet esošu pakalpojumu sniedzēja rezultātu

Izmantojiet PUT, lai saistītu atbalstīta pakalpojumu sniedzēja esošu pārbaudes rezultātu ar savu zīmolu. Tādējādi netiek pasūtīta jauna pārbaude. Iegūstiet pareizo pakalpojumu sniedzēja darījuma identifikatoru un jebkuru nepieciešamo apstiprinājuma pilnvaru tieši no šī pakalpojumu sniedzēja un pārliecinieties, ka pārskats attiecas uz to pašu uzņēmumu.

AUTHPLUS neatbalsta šo importēšanas darbplūsmu. Joprojām ir spēkā konkrētā pakalpojumu sniedzēja atbilstības noteikumi; importēšanas pieprasījums neatceļ šos noteikumus un negarantē atbilstību ikvienam kampaņas lietojuma gadījumam.

Sagatavojiet importēšanu

Ārējās pārbaudes importēšanas lauki
LauksVērtība
evpIdAtbalstīta pakalpojumu sniedzēja identifikators, 1–10 rakstzīmes.
vettingIdPakalpojumu sniedzēja faktiskais pārbaudes darījuma identifikators, līdz 255 rakstzīmēm. Neaizstājiet to ar zīmola identifikatoru un neizdomājiet identifikatoru.
vettingTokenApstiprinājuma pilnvara, ja pakalpojumu sniedzējs to pieprasa, līdz 65535 rakstzīmēm. Glabājiet to slepenībā un neiekļaujiet to, ja pakalpojumu sniedzējs to nepieprasa.

Izveidojiet vetting-import.json, izmantojot faktiskās pakalpojumu sniedzēja vērtības. Nesūtiet tikai atbildei paredzētos vērtējuma, statusa vai laikspiedola laukus tā, it kā tie varētu mainīt rezultātu.

Importējiet rezultātu vienu reizi

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"

Izprotiet esošās maksas

Šis starpniekserveris nereģistrē tikko importētu rezultātu kā jaunu maksas pasūtījumu. Tas neatceļ iepriekš pasūtītu pārbaudi: ja tam pašam vettingId jau ir pasūtījums, kas gaida rezultātu vai maksas iekasēšanu, rezultāta ar statusu ACTIVE vai FAILED importēšana var izraisīt šim pasūtījumam saglabātās maksas iekasēšanu. Šajā sinhronizācijas atzarā par ierakstu, par kuru maksa jau iekasēta, atkārtota maksa netiek iekasēta.

Sekojiet faktiskajam iznākumam

Veiksmīga HTTP atbilde var ietvert pārbaudes ierakstu, kas vēl gaida rezultātu. Saglabājiet tā vettingId un pārbaudiet vettingStatus, iemeslus, vērtējumu un spēkā stāšanās un derīguma beigu datumus, ja tie ir pieejami. PENDING un UNSCORE prasa turpmāku uzraudzību; ACTIVE, FAILED un EXPIRED apzīmē atšķirīgus iznākumus. Pieprasījuma pieņemšana HTTP līmenī pati par sevi neapliecina labvēlīgu vērtējumu vai atbilstību kampaņas prasībām.

Izmantojiet ārējās pārbaudes statusu ieraksta uzraudzībai. Galīgā rezultāta nolasīšana vai importēšana var izraisīt maksas iekasēšanu par agrāku maksas pasūtījumu; tas ne vienmēr nozīmē, ka nav jāsedz esoša nesamaksāta maksa.

Atkārtojiet to pašu iecerēto pieprasījumu

Katrai iecerētajai darbībai izmantojiet vienu Idempotency-Key un saglabājiet precīzu metodi, ceļu, vaicājumu un satura baitus. Atslēgās var būt 1–128 drukājamas ASCII rakstzīmes bez atstarpēm. Pieprasījuma, kas vēl tiek apstrādāts, dublikāts var atgriezt 409 ar Retry-After. Pabeigtiem pieprasījumiem tiek atkārtoti atgriezta to saglabātā atbilde, tostarp kļūdas. Ievērojiet pieprasījumu biežuma ierobežojumus.

Pēc datu pārsūtīšanas kļūmes var tikt atgriezta kešatmiņā saglabāta 502 atbilde. Kešatmiņā saglabāta 500 atbilde ar requestId var nozīmēt, ka reģistrs ir pieņēmis darbību, bet vietējā datu saglabāšana vai norēķinu apstrāde nav izdevusies. Saglabājiet pieprasījuma identifikatoru, pārbaudiet pašreizējos ierakstus un pirms jaunas atslēgas izmantošanas saskaņojiet situāciju ar atbalsta dienestu. Nepieņemiet, ka kļūda nozīmē, ka pasūtījums nepastāv.