Använd ett varumärke för meddelanden som tillhör kontot
Använd ett aktiverat API-konto via HTTPS från en tillåten käll-IP-adress. Autentisering med Basic och Bearer stöds. Varumärkets ID måste tillhöra det kontot. Håll leverantörens token, varumärkets identitetsuppgifter och returnerade rapporter konfidentiella.
Använd ett befintligt resultat från en leverantör
Använd PUT för att koppla ett befintligt granskningsresultat från en leverantör som stöds till ditt varumärke. Detta beställer ingen ny granskning. Hämta leverantörens korrekta transaktions-ID och eventuell bekräftelsetoken direkt från leverantören och säkerställ att rapporten avser samma företagsidentitet.
AUTHPLUS stöder inte detta importflöde. Leverantörsspecifika matchningsregler gäller fortfarande; en importbegäran innebär inget undantag från dem och garanterar inte att kraven för alla kampanjers användningsfall uppfylls.
Förbered importen
| Fält | Värde |
|---|---|
| evpId | ID för en leverantör som stöds, 1–10 tecken. |
| vettingId | Leverantörens faktiska transaktionsidentifierare för granskningen, högst 255 tecken. Använd inte varumärkets ID i stället och hitta inte på en identifierare. |
| vettingToken | Bekräftelsetoken när leverantören kräver det, högst 65535 tecken. Behandla den som en hemlig uppgift och utelämna den när leverantören inte kräver den. |
Skapa vetting-import.json med leverantörens faktiska värden. Skicka inte fält för poäng, status eller tidsstämplar som endast förekommer i svar som om de kunde ändra resultatet.
Importera resultatet en gång
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"Förstå befintliga debiteringar
Ett nyimporterat resultat registreras inte som en ny avgiftsbelagd beställning av denna proxy. Detta avbryter inte en tidigare beställd granskning: om samma vettingId redan har en beställning som väntar på resultat eller debitering kan import av ett resultat med status ACTIVE eller FAILED medföra att dess lagrade avgift debiteras. En tidigare debiterad post debiteras inte igen i denna synkroniseringsgren.
Följ det faktiska utfallet
Ett lyckat HTTP-svar kan innehålla en granskningspost som ännu inte är färdigbehandlad. Spara dess vettingId och kontrollera vettingStatus, orsaker, poäng och giltighetens start- och slutdatum i den mån dessa finns tillgängliga. PENDING och UNSCORE kräver fortsatt uppföljning; ACTIVE, FAILED och EXPIRED beskriver olika utfall. Ett godkännande på HTTP-nivå visar inte i sig att poängen är gynnsam eller att kraven för kampanjen uppfylls.
Använd status för extern granskning för att följa posten. Att läsa eller importera ett slutligt resultat kan medföra debitering för en tidigare avgiftsbelagd beställning; åtgärden är inte nödvändigtvis fri från en redan utestående avgift.
Försök igen med samma avsedda begäran
Använd en Idempotency-Key per avsedd åtgärd och behåll exakt samma metod, sökväg, frågesträng och byte i begärans kropp. Nycklar stöder 1–128 utskrivbara ASCII-tecken utan blanksteg. En dubblett av en pågående begäran kan ge svaret 409 med Retry-After. För slutförda begäranden återges det lagrade svaret, inklusive fel. Följ begränsningarna för anropsfrekvens.
Ett cachat 502-svar kan uppstå efter ett överföringsfel. Ett cachat 500-svar med requestId kan innebära att registret accepterade åtgärden men att lokal permanent lagring eller debitering misslyckades. Spara begärans ID, kontrollera de aktuella posterna och stäm av med supporten innan du använder en ny nyckel. Utgå inte från att felet innebär att det inte finns någon beställning.