
Vue d’ensemble
Un rapport d’e-mail est généré chaque fois qu’un nœud de workflow exécute la fonctionnalité Vérification de l’e-mail. Chaque rapport représente un défi OTP associé à une adresse et contient :- L’adresse
emailvérifiée. - Des indicateurs de risque booléens (
is_breached,is_disposable,is_undeliverable) et le tableau détaillébreaches[]provenant d’une base de données de renseignements sur les fuites de données. - Le nombre de tentatives d’envoi d’OTP (
verification_attempts) et l’horodatage d’approbation. - Un journal chronologique
lifecycle[]de chaque envoi, nouvelle tentative et tentative de vérification du code. - Un tableau
matches[]signalant la présence de la même adresse dans d’autres vérifications d’e-mail approuvées ou sur votre liste de blocage. - Un tableau
warnings[]— les événements de risque émis pendant la vérification (voir les avertissements de la vérification de l’e-mail). - Un
node_idqui identifie le nœud du graphe de workflow ayant produit le rapport (sessions V3 uniquement).
POST /v3/email/send/ envoie le code et POST /v3/email/check/ valide la saisie de l’utilisateur ; les vérifications autonomes finalisées apparaissent sous la même structure de rapport.
Les sessions hébergées limitent par défaut l’utilisateur à 2 saisies de code incorrectes (email_max_check_attempts) et à 2 envois d’OTP — l’envoi initial plus un renvoi (email_max_retries), configurables par nœud de workflow. Le dépassement de l’une ou l’autre de ces limites finalise l’étape avec l’état Declined et la raison EMAIL_CODE_ATTEMPTS_EXCEEDED.
Emplacement dans les réponses de l’API
L’endpoint de décision (GET /v3/session/{sessionId}/decision/) renvoie les rapports d’e-mail sous la clé de tableau au pluriel email_verifications. Ce tableau contient une entrée par nœud de vérification de l’e-mail dans le graphe de workflow — généralement une seule, mais les flux d’authentification renforcée peuvent en générer plusieurs.
null signifie qu’aucune étape de vérification de l’e-mail n’a encore été exécutée. Parcourez le tableau (plutôt que de lire email_verifications[0]) lorsque votre workflow est susceptible de recueillir plusieurs adresses e-mail.
Schéma
Le schéma canonique champ par champ se trouve sur la page Modèles de données.Declined avec l’avertissement de refus automatique UNDELIVERABLE_EMAIL_DETECTED. Seule exception : lorsque l’utilisateur a saisi l’adresse lui-même (elle n’a pas été préremplie lors de la création de la session), un envoi non distribuable renvoie une erreur inline afin qu’il puisse réessayer avec une autre adresse au lieu d’être immédiatement refusé.
Valeurs de statut
Types d’événements du cycle de vie
lifecycle[] est trié par ordre chronologique. Chaque événement comporte type, timestamp, details et un fee facturable (le cas échéant) :
Le payload
details dépend de la famille d’événements :
- Événements d’envoi (
EMAIL_VERIFICATION_MESSAGE_SENT,EMAIL_VERIFICATION_RETRY_MESSAGE_SENT) —{ status, reason }.statusestSuccess,RetryouUndeliverable;reasonestnullsauf si l’envoi a échoué (email_can_not_be_delivered, ouunknownpour des anciennes valeurs non reconnues). - Événements de vérification (
VALID_CODE_ENTERED,INVALID_CODE_ENTERED) —{ code_tried, status }avecstatusApproved,Failed,Expired or Not FoundouDeclined. - Événements de statut final —
null, saufEMAIL_VERIFICATION_DECLINED/EMAIL_VERIFICATION_IN_REVIEW, qui contiennent{ "reason": "<risk code>" }(par ex.UNDELIVERABLE_EMAIL_DETECTED).
status Success ou Undeliverable enregistrent les frais de Vérification de l’e-mail de $0.02 ; les envois Retry, les événements de vérification et les événements de statut portent toujours fee: 0.
Correspondances entre sessions
matches[] enregistre la même adresse sur des vérifications d’e-mail précédemment approuvées au sein de la même application — à travers les sessions KYC, KYB et d’API autonomes — ainsi que les correspondances avec les entrées des listes de blocage configurées via les listes de l’API de gestion. Les vérifications partageant les vendor_data de la session actuelle sont exclues (le même utilisateur final ne correspond pas à lui-même), le tableau est limité à 5 entrées, ordonnées de la plus ancienne à la plus récente. Lorsque l’adresse figure sur votre liste de blocage mais qu’aucune des sessions correspondantes n’est sur liste de blocage, une entrée synthétique avec source: "list_entry" (tous les champs de session à null) est ajoutée au début du tableau.
Exemples
Approuvé — OTP sans problème avec un avertissement informatif
Refusé — adresse non distribuable
Une adresse préremplie qui échoue à la validation de la syntaxe ou à la validation DNS (MX) — ou dont l’e-mail d’OTP ne peut pas être distribué — est immédiatement finalisée avec le statutDeclined. Aucun événement de vérification du code n’apparaît, car aucun code n’est parvenu à l’utilisateur.
Refusé — boîte aux lettres jetable sur liste de blocage
L’utilisateur a saisi l’OTP, mais l’adresse correspondait à une entrée de votre liste de blocage d’e-mails (refus automatique). L’indicateur jetable est également activé — au niveauinformation ici car disposable_email_action est laissé à sa valeur par défaut NO_ACTION.
Liens associés
- Vue d’ensemble de la Vérification de l’e-mail — fonctionnement et tarifs de la fonctionnalité.
- Avertissements de la Vérification de l’e-mail — l’ensemble des codes de risque, des déclencheurs de refus et des actions configurables.
- Modèles de données — vérification de l’e-mail — schéma canonique champ par champ.
- API Email — Envoyer un OTP et Vérifier un OTP — endpoints serveur à serveur autonomes.
- API de gestion — Listes — gérer la liste de blocage d’e-mails qui alimente
matches[]avecsource: list_entry.