
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
emailverificada. - Indicadors de risc booleans (
is_breached,is_disposable,is_undeliverable) i l’array complementaribreaches[]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_idque identifica quin node del graf del flux de treball ha generat l’informe (només en sessions V3).
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.
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.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ésSuccess,RetryoUndeliverable;reasonésnulltret que l’enviament hagi fallat (email_can_not_be_delivered, ounknownper a valors heretats no reconeguts). - Esdeveniments de comprovació (
VALID_CODE_ENTERED,INVALID_CODE_ENTERED) —{ code_tried, status }ambstatusApproved,Failed,Expired or Not FoundoDeclined. - Esdeveniments d’estat final —
null, excepteEMAIL_VERIFICATION_DECLINED/EMAIL_VERIFICATION_IN_REVIEW, que contenen{ "reason": "<risk code>" }(per exemple,UNDELIVERABLE_EMAIL_DETECTED).
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 aDeclined. 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 nivellinformation, perquè disposable_email_action manté el seu valor predeterminat NO_ACTION.
Relacionat
- Visió general de la Verificació de correu electrònic — comportament de la funcionalitat i preus.
- Advertències de la Verificació de correu electrònic — tots els codis de risc, activadors de rebuig i accions configurables.
- Models de dades — verificació de correu electrònic — esquema canònic camp per camp.
- API de correu electrònic — Enviar OTP i Comprovar OTP — endpoints independents de servidor a servidor.
- Management API — Llistes — gestiona la llista de bloqueig de correu electrònic que alimenta
matches[]ambsource: list_entry.