Sviluppatori

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

Importare un risultato di verifica esistente

Associa al tuo marchio un risultato esistente di un fornitore supportato.

Su questa pagina
  1. Usa un marchio di messaggistica appartenente all'account
  2. Usa un risultato esistente del fornitore
  3. Prepara l'importazione
  4. Importa il risultato una sola volta
  5. Comprendi gli addebiti esistenti
  6. Segui l'esito effettivo
  7. Riprova la stessa richiesta prevista

Usa un marchio di messaggistica appartenente all'account

Usa un account API abilitato tramite HTTPS da un indirizzo IP di origine consentito. Sono supportate le autenticazioni Basic e Bearer. L'identificativo del marchio deve appartenere a tale account. Mantieni riservati i token del fornitore, i dati identificativi del marchio e i rapporti restituiti.

Usa un risultato esistente del fornitore

Usa PUT per associare al tuo marchio un risultato di verifica esistente di un fornitore supportato. Questa operazione non ordina una nuova verifica. Ottieni l'identificativo corretto della transazione del fornitore e l'eventuale token di conferma direttamente dal fornitore stesso e assicurati che il rapporto si riferisca alla stessa identità aziendale.

AUTHPLUS non supporta questa procedura di importazione. Continuano ad applicarsi le regole di corrispondenza specifiche del fornitore; una richiesta di importazione non le elimina né garantisce l'idoneità per ogni caso d'uso delle campagne.

Prepara l'importazione

Campi per l'importazione della verifica esterna
CampoValore
evpIdIdentificativo di un fornitore supportato, da 1–10 caratteri.
vettingIdL'identificativo effettivo della transazione di verifica del fornitore, fino a 255 caratteri. Non usare al suo posto l'identificativo del marchio e non inventare un identificativo.
vettingTokenToken di conferma quando richiesto dal fornitore, fino a 65535 caratteri. Trattalo come un segreto e omettilo quando il fornitore non lo richiede.

Crea vetting-import.json usando i valori effettivi del fornitore. Non inviare i campi relativi a punteggio, stato o data e ora, presenti solo nella risposta, come se potessero modificare il risultato.

Importa il risultato una sola volta

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"

Comprendi gli addebiti esistenti

Un risultato appena importato non viene registrato da questo proxy come un nuovo ordine a pagamento. Ciò non annulla una verifica ordinata in precedenza: quando allo stesso vettingId è già associato un ordine in attesa del risultato o dell'addebito, l'importazione di un risultato ACTIVE o FAILED può comportare il saldo della tariffa memorizzata per tale ordine. Questo ramo di sincronizzazione non addebita nuovamente una registrazione già addebitata.

Segui l'esito effettivo

Una risposta HTTP riuscita può contenere una registrazione di verifica ancora in sospeso. Conservane il vettingId ed esamina vettingStatus, motivazioni, punteggio e date di decorrenza e scadenza, se disponibili. PENDING e UNSCORE richiedono ulteriore monitoraggio; ACTIVE, FAILED e EXPIRED descrivono esiti diversi. La sola accettazione HTTP non dimostra un punteggio favorevole né l'idoneità per le campagne.

Usa lo stato della verifica esterna per seguire la registrazione. La lettura o l'importazione di un risultato definitivo può comportare il saldo di un precedente ordine a pagamento; non è necessariamente esente da un addebito già in sospeso.

Riprova la stessa richiesta prevista

Usa una Idempotency-Key per ogni operazione prevista e conserva esattamente il metodo, il percorso, la stringa di query e i byte del corpo. Le chiavi supportano 1–128 caratteri ASCII stampabili senza spazi. Un duplicato di una richiesta in corso può restituire 409 con Retry-After. Le richieste completate restituiscono nuovamente la risposta memorizzata, inclusi gli errori. Rispetta i limiti di frequenza delle richieste.

Un errore 502 memorizzato nella cache può verificarsi a seguito di un errore di trasporto. Un errore 500 memorizzato nella cache con requestId può indicare che il registro ha accettato l'operazione, ma il salvataggio persistente locale o la fatturazione non sono riusciti. Conserva l'identificativo della richiesta, esamina le registrazioni attuali e chiarisci la situazione con l'assistenza prima di usare una nuova chiave. Non presumere che l'errore significhi che non esiste alcun ordine.