Saltar al contingut principal
L’informe de Verificació de correu electrònic recull el resultat complet d’un desafiament OTP per correu electrònic: a qui es va enviar el missatge, si l’adreça és d’un sol ús o no lliurable, si apareix en filtracions de dades conegudes, quants intents ha necessitat l’usuari i qualsevol coincidència entre sessions amb la teva llista de bloqueig o altres usuaris aprovats. Aquesta pàgina documenta l’estructura JSON retornada per l’endpoint de decisió perquè puguis analitzar els resultats de l’OTP, l’exposició a filtracions i els indicadors de risc de cada adreça verificada.
Informe de verificació de correu electrònic de Didit que mostra el resultat de l'OTP, les dades de filtracions i els indicadors de risc

Visió general

Es genera un informe de correu electrònic cada vegada que un node del flux de treball executa la funcionalitat de Verificació de correu electrònic. Cada informe representa un desafiament OTP per a una adreça i conté:
  • L’adreça email verificada.
  • Indicadors de risc booleans (is_breached, is_disposable, is_undeliverable) i l’array complementari breaches[] procedent d’una base de dades d’intel·ligència de filtracions.
  • El recompte d’intents d’enviament de l’OTP (verification_attempts) i la marca de temps d’aprovació.
  • Un registre cronològic lifecycle[] de cada intent d’enviament, reintent i comprovació de codi.
  • Un array matches[] que mostra la mateixa adreça en altres verificacions de correu electrònic aprovades o a la teva llista de bloqueig.
  • Un array warnings[]: esdeveniments de risc emesos durant la verificació (consulta Advertències de Verificació de correu electrònic).
  • Un node_id que identifica quin node del graf del flux de treball ha generat l’informe (només en sessions V3).
En sessions de flux de treball allotjades, el desafiament OTP s’executa dins de la IU de verificació de Didit; només cal que llegeixis el resultat del payload de decisió. Per a un OTP de servidor a servidor sense un flux allotjat, utilitza l’API independent de correu electrònic: POST /v3/email/send/ lliura el codi i POST /v3/email/check/ valida l’entrada de l’usuari; les verificacions independents finalitzades es mostren mitjançant la mateixa estructura d’informe. Per defecte, les sessions allotjades limiten l’usuari a 2 entrades de codi incorrectes (email_max_check_attempts) i 2 enviaments d’OTP: l’enviament inicial més un reenviament (email_max_retries), configurable per cada node del flux de treball. Si se supera qualsevol dels dos límits, el pas finalitza com a Declined amb EMAIL_CODE_ATTEMPTS_EXCEEDED.

On apareix a les respostes de l’API

L’endpoint de decisió (GET /v3/session/{sessionId}/decision/) retorna informes de correu electrònic sota la clau d’array en plural email_verifications. L’array conté una entrada per cada node de Verificació de correu electrònic al graf del flux de treball; normalment una, però els fluxos amb verificació addicional (step-up) en poden generar diverses.
Un valor null significa que encara no s’ha executat cap pas de Verificació de correu electrònic. Itera l’array (en lloc de llegir email_verifications[0]) quan el teu flux de treball pugui recopilar més d’una adreça de correu electrònic.

Esquema

L’esquema canònic camp per camp es troba a la pàgina Models de dades.
Una adreça no lliurable (sintaxi no vàlida, un domini inexistent, registres MX absents o un lliurament d’OTP fallit) finalitza el pas com a Declined amb l’advertència de rebuig automàtic UNDELIVERABLE_EMAIL_DETECTED. L’única excepció: quan l’usuari ha escrit l’adreça ell mateix (no s’ha emplenat prèviament en crear la sessió), un enviament no lliurable retorna un error en línia per tal que pugui reintentar-ho amb una adreça diferent en lloc de ser rebutjat immediatament.

Valors d’estat

Tipus d’esdeveniments del cicle de vida

lifecycle[] està ordenat cronològicament. Cada esdeveniment té type, timestamp, details i una fee facturable (quan correspongui): El payload de details depèn de la família d’esdeveniments:
  • Esdeveniments d’enviament (EMAIL_VERIFICATION_MESSAGE_SENT, EMAIL_VERIFICATION_RETRY_MESSAGE_SENT) — { status, reason }. status és Success, Retry o Undeliverable; reason és null tret que l’enviament hagi fallat (email_can_not_be_delivered, o unknown per a valors heretats no reconeguts).
  • Esdeveniments de comprovació (VALID_CODE_ENTERED, INVALID_CODE_ENTERED) — { code_tried, status } amb status Approved, Failed, Expired or Not Found o Declined.
  • Esdeveniments d’estat final — null, excepte EMAIL_VERIFICATION_DECLINED / EMAIL_VERIFICATION_IN_REVIEW, que contenen { "reason": "<risk code>" } (per exemple, UNDELIVERABLE_EMAIL_DETECTED).
Els enviaments amb status Success o Undeliverable registren la tarifa de Verificació de correu electrònic de $0.02; els enviaments Retry, els esdeveniments de comprovació i els esdeveniments d’estat sempre porten fee: 0.

Coincidències entre sessions

matches[] registra la mateixa adreça en verificacions de correu electrònic aprovades prèviament a la mateixa aplicació —entre sessions de KYC, KYB i de l’API independent—, a més de coincidències amb la llista de bloqueig configurada a les llistes de l’API de gestió. S’exclouen les verificacions que comparteixen el vendor_data de la sessió actual (el mateix usuari final no coincideix amb si mateix), la matriu està limitada a 5 entrades, ordenades de més antiga a més recent. Quan l’adreça és a la teva llista de bloqueig però cap de les sessions coincidents està a la llista de bloqueig, s’anteposa a la matriu una entrada sintètica amb source: "list_entry" (tots els camps de la sessió a null).

Exemples

Aprovada — OTP net amb una alerta informativa

Rebutjada — adreça no lliurable

Una adreça emplenada prèviament que no supera la validació de sintaxi o DNS (MX) —o el correu electrònic amb l’OTP de la qual no es pot lliurar— finalitza immediatament com a Declined. No apareix cap esdeveniment de comprovació de codi perquè no va arribar mai cap codi a l’usuari.

Rebutjada — bústia d’un sol ús a la llista de bloqueig

L’usuari ha completat l’OTP, però l’adreça ha coincidit amb la teva llista de bloqueig de correu electrònic (rebuig automàtic). L’indicador de bústia d’un sol ús també s’activa —aquí, amb nivell information, perquè disposable_email_action manté el seu valor predeterminat NO_ACTION.

Relacionat

Darrera modificació el 7 de novembre del 2026