Vai al contenuto principale
Il report di Verifica email acquisisce l’esito completo di una verifica OTP via email: a chi è stato inviato il messaggio, se l’indirizzo è usa e getta o non recapitabile, se compare in violazioni dei dati note, quanti tentativi ha effettuato l’utente ed eventuali corrispondenze tra sessioni diverse rispetto alla tua blocklist o ad altri utenti approvati. Questa pagina documenta la struttura JSON restituita dall’endpoint di decisione, consentendoti di analizzare gli esiti degli OTP, l’esposizione a violazioni e i flag di rischio per ciascun indirizzo verificato.
Report di verifica email di Didit che mostra l'esito dell'OTP, i dati sulle violazioni e i flag di rischio

Panoramica

Viene generato un report email ogni volta che un nodo del workflow esegue la funzionalità Verifica email. Ciascun report rappresenta una verifica OTP per un singolo indirizzo e contiene:
  • L’indirizzo email verificato.
  • Flag di rischio booleani (is_breached, is_disposable, is_undeliverable) e l’array di supporto breaches[] proveniente da un database di informazioni sulle violazioni.
  • Il conteggio dei tentativi di invio dell’OTP (verification_attempts) e il timestamp di approvazione.
  • Un registro cronologico lifecycle[] di ogni tentativo di invio, nuovo tentativo e verifica del codice.
  • Un array matches[] che evidenzia lo stesso indirizzo presente in altre verifiche email approvate o nella tua blocklist.
  • Un array warnings[] — eventi di rischio generati durante la verifica (vedi Avvisi di Verifica email).
  • Un node_id che identifica quale nodo del grafo del workflow ha prodotto il report (solo sessioni V3).
Nelle sessioni di workflow ospitate, la verifica OTP viene eseguita all’interno dell’interfaccia utente di verifica di Didit — ti basta leggere il risultato dal payload di decisione. Per gli OTP da server a server senza un flusso ospitato, utilizza l’API Email autonoma: POST /v3/email/send/ invia il codice e POST /v3/email/check/ convalida il codice inserito dall’utente; le verifiche autonome completate vengono presentate con la stessa struttura del report. Le sessioni ospitate limitano l’utente a un massimo di 2 inserimenti errati del codice (email_max_check_attempts) e 2 invii di OTP — l’invio iniziale più un reinvio (email_max_retries) per impostazione predefinita, configurabili per nodo del workflow. Il superamento di uno dei due limiti finalizza il passaggio con lo stato Declined con EMAIL_CODE_ATTEMPTS_EXCEEDED.

Dove compare nelle risposte API

L’endpoint di decisione (GET /v3/session/{sessionId}/decision/) restituisce i report email sotto la chiave dell’array in forma plurale email_verifications. L’array contiene una voce per ogni nodo di Verifica email nel grafo del workflow — in genere una, ma i flussi di step-up possono produrne diverse.
Un valore null indica che non è ancora stato eseguito alcun passaggio di Verifica email. Itera sull’array (invece di leggere solo email_verifications[0]) se il tuo workflow può raccogliere più di un indirizzo email.

Schema

Lo schema canonico campo per campo è disponibile nella pagina Modelli di dati.
Un indirizzo non recapitabile — per sintassi non valida, dominio inesistente, record MX mancanti o mancata consegna dell’OTP — finalizza il passaggio come Declined con l’avviso di rifiuto automatico UNDELIVERABLE_EMAIL_DETECTED. L’unica eccezione: quando l’utente ha digitato personalmente l’indirizzo (non è stato precompilato al momento della creazione della sessione), un invio non recapitabile restituisce un errore inline così da consentirgli di riprovare con un indirizzo diverso anziché essere rifiutato immediatamente.

Valori di stato

Tipi di eventi del ciclo di vita

lifecycle[] è ordinato cronologicamente. Ciascun evento include type, timestamp, details e una fee fatturabile (se applicabile): Il payload di details dipende dalla famiglia dell’evento:
  • Eventi di invio (EMAIL_VERIFICATION_MESSAGE_SENT, EMAIL_VERIFICATION_RETRY_MESSAGE_SENT) — { status, reason }. status è Success, Retry o Undeliverable; reason è null a meno che l’invio non sia fallito (email_can_not_be_delivered, o unknown per valori legacy non riconosciuti).
  • Eventi di controllo (VALID_CODE_ENTERED, INVALID_CODE_ENTERED) — { code_tried, status } con status Approved, Failed, Expired or Not Found o Declined.
  • Eventi di stato finale — null, eccetto EMAIL_VERIFICATION_DECLINED / EMAIL_VERIFICATION_IN_REVIEW, che contengono { "reason": "<risk code>" } (ad es. UNDELIVERABLE_EMAIL_DETECTED).
Gli invii con status Success o Undeliverable registrano la tariffa di Verifica email pari a $0.02; gli invii Retry, gli eventi di controllo e gli eventi di stato riportano sempre fee: 0.

Corrispondenze tra sessioni

matches[] registra lo stesso indirizzo su verifiche email precedentemente approvate nella stessa applicazione — tra sessioni KYC, KYB e API standalone — oltre alle corrispondenze con gli elementi della blocklist configurati nelle liste della Management API. Le verifiche che condividono il vendor_data della sessione corrente sono escluse (lo stesso utente finale non genera corrispondenze con se stesso), l’array è limitato a un massimo di 5 voci, ordinate dalla più datata alla più recente. Quando l’indirizzo è presente nella tua blocklist ma nessuna delle sessioni corrispondenti è inclusa nella blocklist, all’array viene anteposta una voce sintetica con source: "list_entry" (tutti i campi della sessione impostati su null).

Esempi

Approvata — OTP pulito con un avviso informativo

Rifiutata — indirizzo non recapitabile

Un indirizzo precompilato che non supera la validazione della sintassi o del DNS (MX) — o la cui email con OTP non può essere recapitata — si finalizza immediatamente come Declined. Non compare alcun evento di verifica del codice poiché nessun codice ha mai raggiunto l’utente.

Rifiutata — casella di posta usa e getta inclusa nella blocklist

L’utente ha completato l’OTP, ma l’indirizzo corrispondeva a un elemento della tua blocklist email (rifiuto automatico). Viene segnalato anche il flag che indica un indirizzo email usa e getta — qui a livello information poiché disposable_email_action è rimasto impostato sul valore predefinito NO_ACTION.

Risorse correlate

Ultima modifica il 7 novembre 2026