
Descripción general
Se genera un informe de correo electrónico cada vez que un nodo de un flujo de verificación (workflow) ejecuta la función de Verificación de correo electrónico. Cada informe representa un desafío OTP para una dirección y contiene:- La dirección
emailverificada. - Indicadores de riesgo booleanos (
is_breached,is_disposable,is_undeliverable) y el arraybreaches[]que los respalda, obtenido de una base de datos de inteligencia sobre filtraciones. - El número de intentos de envío del OTP (
verification_attempts) y la marca de tiempo de aprobación. - Un registro cronológico
lifecycle[]de cada envío, reintento e intento de comprobación del código. - Un array
matches[]que muestra la misma dirección en otras verificaciones de correo electrónico aprobadas o en tu lista de bloqueo. - Un array
warnings[]con los eventos de riesgo emitidos durante la verificación (consulta Advertencias de la Verificación de correo electrónico). - Un
node_idque identifica qué nodo del grafo del flujo generó el informe (solo en sesiones V3).
POST /v3/email/send/ envía el código y POST /v3/email/check/ valida la entrada del usuario. Las verificaciones independientes finalizadas siguen la misma estructura de informe.
De forma predeterminada, las sesiones alojadas limitan al usuario a 2 intentos incorrectos de introducir el código (email_max_check_attempts) y a 2 envíos de OTP: el envío inicial más un reenvío (email_max_retries), valores que se pueden ajustar en cada nodo del flujo. Superar cualquiera de los dos límites finaliza el paso como Declined con EMAIL_CODE_ATTEMPTS_EXCEEDED.
Dónde aparece en las respuestas de la API
El endpoint de decisión (GET /v3/session/{sessionId}/decision/) devuelve los informes de verificación de correo electrónico con la clave de array en plural email_verifications. El array contiene una entrada por cada nodo de Verificación de correo electrónico del grafo del flujo: normalmente una, pero los flujos de verificación reforzada (step-up) pueden generar varias.
null significa que todavía no se ha ejecutado ningún paso de Verificación de correo electrónico. Recorre el array (en lugar de leer email_verifications[0]) cuando tu flujo pueda recopilar más de una dirección de correo electrónico.
Esquema
El esquema de referencia, campo por campo, está en la página Modelos de datos.Declined con la advertencia de rechazo automático UNDELIVERABLE_EMAIL_DETECTED. La única excepción: cuando el usuario escribió la dirección él mismo (no venía rellenada al crear la sesión), un envío no entregable devuelve un error en línea para que pueda reintentar con otra dirección, en lugar de rechazarlo de inmediato.
Valores de estado
Tipos de eventos del ciclo de vida
lifecycle[] está ordenado cronológicamente. Cada evento tiene type, timestamp, details y un cargo facturable fee (cuando corresponde):
El payload de
details depende de la familia del evento:
- Eventos de envío (
EMAIL_VERIFICATION_MESSAGE_SENT,EMAIL_VERIFICATION_RETRY_MESSAGE_SENT):{ status, reason }.statusesSuccess,RetryoUndeliverable;reasonesnullsalvo que el envío haya fallado (email_can_not_be_delivered, ounknownpara valores heredados no reconocidos). - Eventos de comprobación (
VALID_CODE_ENTERED,INVALID_CODE_ENTERED):{ code_tried, status }, constatusigual aApproved,Failed,Expired or Not FoundoDeclined. - Eventos de estado final:
null, exceptoEMAIL_VERIFICATION_DECLINED/EMAIL_VERIFICATION_IN_REVIEW, que incluyen{ "reason": "<risk code>" }(por ejemplo,UNDELIVERABLE_EMAIL_DETECTED).
status Success o Undeliverable registran la tarifa de Verificación de correo electrónico de $0.02; los envíos Retry, los eventos de comprobación y los eventos de estado siempre llevan fee: 0.
Coincidencias entre sesiones
matches[] registra la misma dirección en verificaciones de correo electrónico aprobadas anteriormente dentro de la misma aplicación (en sesiones de KYC, KYB y de la API independiente), además de las coincidencias con la lista de bloqueo configuradas en las listas de la API de gestión. Se excluyen las verificaciones que comparten el vendor_data de la sesión actual (el mismo usuario final no coincide consigo mismo); el array tiene un máximo de 5 entradas, ordenadas de la más antigua a la más reciente. Cuando la dirección está en tu lista de bloqueo, pero ninguna de las sesiones coincidentes figura en la lista de bloqueo, se añade al principio del array una entrada sintética con source: "list_entry" (con todos los campos de sesión en null).
Ejemplos
Aprobado: OTP correcto con un incumplimiento de nivel informativo
Rechazado: dirección no entregable
Una dirección precompletada que no supera la validación de sintaxis o de DNS (MX), o cuyo correo con el OTP no se puede entregar, se cierra de inmediato comoDeclined. No aparecen eventos de comprobación de código porque ningún código llegó al usuario.
Rechazado: buzón desechable en la lista de bloqueo
El usuario completó el OTP, pero la dirección coincidió con tu lista de bloqueo de correos electrónicos (rechazo automático). También se activa el indicador de correo desechable, aquí con nivelinformation porque disposable_email_action se mantiene en su valor predeterminado NO_ACTION.
Relacionado
- Visión general de la Verificación de correo electrónico: comportamiento de la función y precios.
- Advertencias de la Verificación de correo electrónico: todos los códigos de riesgo, los disparadores de rechazo y las acciones configurables.
- Modelos de datos: verificación de correo electrónico: esquema de referencia campo por campo.
- API de correo electrónico: enviar OTP y comprobar OTP: endpoints independientes de servidor a servidor.
- API de gestión: listas: gestiona la lista de bloqueo de correos electrónicos que genera coincidencias en
matches[]consource: list_entry.