Bruk en merkevare for meldingssending som tilhører kontoen
Bruk en aktivert API-konto over HTTPS fra en tillatt kilde-IP-adresse. Autentisering med Basic og Bearer støttes. Merkevare-ID-en må tilhøre denne kontoen. Hold leverandørtokener, merkevarens identitetsopplysninger og returnerte rapporter private.
Bruk et eksisterende resultat fra leverandøren
Bruk PUT til å knytte et eksisterende kontrollresultat fra en støttet leverandør til merkevaren din. Dette bestiller ikke en ny kontroll. Hent riktig transaksjons-ID og eventuelt bekreftelsestoken direkte fra leverandøren, og sørg for at rapporten gjelder samme virksomhetsidentitet.
AUTHPLUS støtter ikke denne importprosessen. Leverandørens egne regler for samsvar gjelder fortsatt; en importforespørsel opphever dem ikke og garanterer heller ikke kvalifisering for alle bruksområder for kampanjer.
Forbered importen
| Felt | Verdi |
|---|---|
| evpId | ID for en støttet leverandør, 1–10 tegn. |
| vettingId | Leverandørens faktiske transaksjonsidentifikator for kontrollen, opptil 255 tegn. Ikke erstatt den med merkevare-ID-en eller finn på en identifikator. |
| vettingToken | Bekreftelsestoken når leverandøren krever det, opptil 65535 tegn. Behandle det som en hemmelighet, og utelat det når leverandøren ikke krever det. |
Opprett vetting-import.json med de faktiske verdiene fra leverandøren. Ikke send felter for poengsum, status eller tidsstempel som bare hører til i svaret, som om de kunne endre resultatet.
Importer resultatet én gang
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"Forstå eksisterende gebyrer
Denne proxyen registrerer ikke et nylig importert resultat som en ny betalt bestilling. Dette kansellerer ikke en tidligere bestilt kontroll: Når samme vettingId allerede har en bestilling som venter på resultat eller belastning, kan import av et resultat med ACTIVE eller FAILED gjøre opp det lagrede gebyret for bestillingen. En oppføring som allerede er belastet, belastes ikke på nytt av denne synkroniseringsgrenen.
Følg det faktiske utfallet
Et vellykket HTTP-svar kan inneholde en kontrolloppføring som fortsatt venter på behandling. Ta vare på oppføringens vettingId, og undersøk vettingStatus, begrunnelser, poengsum og datoer for ikrafttredelse og utløp der de er tilgjengelige. PENDING og UNSCORE krever videre oppfølging; ACTIVE, FAILED og EXPIRED beskriver ulike utfall. Aksept på HTTP-nivå alene beviser ikke en gunstig poengsum eller kvalifisering for en kampanje.
Bruk status for ekstern kontroll for å følge oppføringen. Lesing eller import av et sluttresultat kan gjøre opp en tidligere betalt bestilling; det innebærer ikke nødvendigvis fritak fra et eksisterende utestående gebyr.
Prøv den samme tilsiktede forespørselen på nytt
Bruk én Idempotency-Key per tilsiktet operasjon, og behold nøyaktig samme metode, sti, spørring og byte i forespørselskroppen. Nøkler støtter 1–128 utskrivbare ASCII-tegn uten mellomrom. En duplikatforespørsel mens den opprinnelige behandles, kan returnere 409 med Retry-After. For fullførte forespørsler returneres det lagrede svaret på nytt, inkludert feil. Overhold grensene for forespørselsfrekvens.
En mellomlagret 502 kan følge etter en transportfeil. En mellomlagret 500 med requestId kan bety at registeret godtok operasjonen, men at lokal varig lagring eller fakturering mislyktes. Ta vare på forespørsels-ID-en, undersøk de gjeldende oppføringene, og avklar statusen med kundestøtte før du bruker en ny nøkkel. Ikke anta at feilen betyr at ingen bestilling finnes.