
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
emailverificato. - Flag di rischio booleani (
is_breached,is_disposable,is_undeliverable) e l’array di supportobreaches[]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_idche identifica quale nodo del grafo del workflow ha prodotto il report (solo sessioni V3).
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.
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.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,RetryoUndeliverable;reasonènulla meno che l’invio non sia fallito (email_can_not_be_delivered, ounknownper valori legacy non riconosciuti). - Eventi di controllo (
VALID_CODE_ENTERED,INVALID_CODE_ENTERED) —{ code_tried, status }constatusApproved,Failed,Expired or Not FoundoDeclined. - Eventi di stato finale —
null, eccettoEMAIL_VERIFICATION_DECLINED/EMAIL_VERIFICATION_IN_REVIEW, che contengono{ "reason": "<risk code>" }(ad es.UNDELIVERABLE_EMAIL_DETECTED).
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 comeDeclined. 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 livelloinformation poiché disposable_email_action è rimasto impostato sul valore predefinito NO_ACTION.
Risorse correlate
- Panoramica di Verifica email — funzionamento e prezzi della funzionalità.
- Avvisi di Verifica email — tutti i codici di rischio, trigger di rifiuto e azioni configurabili.
- Modelli di dati — verifica email — schema canonico campo per campo.
- API Email — Invia OTP e Verifica OTP — endpoint server-to-server standalone.
- Management API — Liste — gestisci la blocklist di email che alimenta
matches[]consource: list_entry.