Passer au contenu principal
Le rapport de vérification de l’e-mail présente le résultat complet d’un défi OTP par e-mail : à qui le message a été envoyé, si l’adresse est jetable ou non distribuable, si elle apparaît dans des fuites de données connues, le nombre de tentatives effectuées par l’utilisateur, ainsi que toute correspondance inter-sessions avec votre liste de blocage ou d’autres utilisateurs approuvés. Cette page documente la structure JSON renvoyée par l’endpoint de décision afin que vous puissiez analyser les résultats OTP, l’exposition aux fuites de données et les indicateurs de risque pour chaque adresse vérifiée.
Rapport Didit de vérification de l'e-mail montrant le résultat OTP, les données de fuites et les indicateurs de risque

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 email vé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_id qui identifie le nœud du graphe de workflow ayant produit le rapport (sessions V3 uniquement).
Dans les sessions de workflow hébergées, le défi OTP s’exécute dans l’interface utilisateur de vérification de Didit — vous lisez simplement le résultat à partir du payload de décision. Pour un OTP de serveur à serveur sans flux hébergé, utilisez l’API Email autonome : 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.
Une valeur 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.
Une adresse non distribuable — syntaxe invalide, domaine inexistant, enregistrements MX manquants ou échec de livraison de l’OTP — finalise l’étape en 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 }. status est Success, Retry ou Undeliverable ; reason est null sauf si l’envoi a échoué (email_can_not_be_delivered, ou unknown pour des anciennes valeurs non reconnues).
  • Événements de vérification (VALID_CODE_ENTERED, INVALID_CODE_ENTERED) — { code_tried, status } avec status Approved, Failed, Expired or Not Found ou Declined.
  • Événements de statut final — null, sauf EMAIL_VERIFICATION_DECLINED / EMAIL_VERIFICATION_IN_REVIEW, qui contiennent { "reason": "<risk code>" } (par ex. UNDELIVERABLE_EMAIL_DETECTED).
Les envois avec le 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 statut Declined. 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 niveau information ici car disposable_email_action est laissé à sa valeur par défaut NO_ACTION.

Liens associés

Dernière modification le 7 novembre 2026