GET /v3/session/<id>/decision/ y todos los webhooks de Didit.
Todos los valores de estado
Cada estado es una cadena exacta que devuelven la API y los webhooks de Didit. Usa siempre una comparación estricta de cadenas (por ejemplo,
=== "In Review") en tu código: estos valores distinguen entre mayúsculas y minúsculas e incluyen espacios. El valor Kyc Expired además lleva una sola K mayúscula (no KYC).Estados de sesión
No iniciada — "Not Started"
No iniciada — "Not Started"
Valor en la API:
"Not Started"La sesión se creó mediante la API, pero el usuario todavía no ha abierto el enlace de verificación.- Qué hacer: espera a que el usuario empiece o envíale un recordatorio si pasa demasiado tiempo.
- Pasa a:
"In Progress","Expired"
En curso — "In Progress"
En curso — "In Progress"
Valor en la API:
"In Progress"El usuario abrió el enlace y está completando los pasos de verificación (captura del documento, prueba de vida, etc.).- Qué hacer: no hace falta ninguna acción: el usuario está avanzando por el flujo.
- Pasa a:
"Approved","Declined","In Review","Abandoned"
Aprobada — "Approved"
Aprobada — "Approved"
Valor en la API:
"Approved"Todas las comprobaciones de verificación se superaron correctamente. La identidad del usuario quedó verificada.- Qué hacer: concede acceso al usuario, actualiza su perfil y guarda los datos de la decisión.
- El webhook incluye: el objeto
decisioncompleto con los resultados de todas las funciones. - Pasa a:
"Kyc Expired"(cuando vence la fecha de caducidad del documento verificado; es el comportamiento predeterminado, salvo que Expiration mode esté en Allow expired para ese país y tipo de documento). Un revisor o el endpoint de actualización de estado también pueden cambiarla a"Declined"o"Resubmitted".
Rechazada — "Declined"
Rechazada — "Declined"
Valor en la API:
"Declined"Al menos una comprobación de verificación falló. El usuario no superó la verificación.- Qué hacer: notifica al usuario. Si el problema tiene solución, puedes solicitar un reenvío.
- El webhook incluye: el objeto
decisioncompleto con advertencias que explican el fallo. - Pasa a:
"Resubmitted"(si un revisor lo solicita). Un revisor o el endpoint de actualización de estado también pueden cambiarla a"Approved".
En revisión — "In Review"
En revisión — "In Review"
Valor en la API:
"In Review"Las comprobaciones automáticas detectaron advertencias que requieren revisión humana. Un revisor de cumplimiento debe tomar la decisión final.- Qué hacer: un revisor debe abrir la sesión en la consola y aprobarla, rechazarla o solicitar un reenvío.
- El webhook incluye: el objeto
decisioncompleto con las advertencias. - Pasa a:
"Approved","Declined","Resubmitted"
En espera del usuario — "Awaiting User"
En espera del usuario — "Awaiting User"
Valor en la API:
"Awaiting User"Se usa en sesiones de KYB (verificación de empresas) cuando el paso de Personas clave ha enviado la lista de partes y ha generado sesiones KYC / KYB hijas. La sesión principal espera hasta que todas las partes obligatorias completen su verificación individual.- Qué hacer: supervisa los estados de las sesiones KYC hijas. Cuando todas las partes obligatorias terminan (aprobadas, rechazadas o expiradas), la sesión principal vuelve a agregar los resultados automáticamente para obtener su estado final.
- El webhook incluye: la lista actual de partes y los estados de sus sesiones hijas.
- Pasa a:
"Approved","Declined","In Review"(cuando todas las sesiones hijas están en un estado final) - Viene de:
"In Progress"(después de enviar el paso de Personas clave) - Nota: si una sesión KYC hija se reenvía, la sesión principal vuelve a
"Awaiting User"hasta que se complete la sesión reenviada. Un resultado"Declined"en la comprobación de registro KYB tiene prioridad sobre"Awaiting User".
Reenviada — "Resubmitted"
Reenviada — "Resubmitted"
Valor en la API:
"Resubmitted"Un revisor solicitó que el usuario repita pasos de verificación concretos (por ejemplo, volver a fotografiar un documento borroso).- Qué hacer: espera a que el usuario complete los pasos reenviados. El sistema vuelve a evaluar la sesión automáticamente.
- El webhook incluye: el objeto
resubmit_infocon la lista de funciones que se deben repetir y los motivos. - Pasa a:
"Approved","Declined","In Review", o"Abandoned"si el plazo de la sesión termina antes de que la persona repita los pasos.
Expirada — "Expired"
Expirada — "Expired"
Valor en la API:
"Expired"La sesión caducó antes de que el usuario abriera el enlace de verificación.- Qué hacer: crea una sesión nueva y envía al usuario un enlace nuevo.
- Estado final: no hay más transiciones.
Abandonada — "Abandoned"
Abandonada — "Abandoned"
Valor en la API:
"Abandoned"El usuario empezó la verificación, pero no la terminó dentro del plazo permitido.- Qué hacer: envía un recordatorio o crea una sesión nueva.
- Sin transiciones automáticas. Un revisor, o
PATCH /v3/session/{sessionId}/update-status/, todavía puede cambiarla a"Approved","Declined"o"Resubmitted".
KYC expirado — "Kyc Expired"
KYC expirado — "Kyc Expired"
Valor en la API:
"Kyc Expired"El documento verificado durante la sesión superó su propia fecha de caducidad. El disparador es esa fecha, no un plazo contado desde la aprobación, y no se envía ningún aviso previo.- Qué hacer: pide al usuario que vuelva a verificarse con una sesión nueva.
status.updatednotifica la transición, y el resultado de la verificación de identidad incluye la advertenciaDOCUMENT_EXPIRED. - Se controla con: el Expiration mode de ese país y tipo de documento en ID verification → Additional settings by country & document type: Reject expired (el valor predeterminado) supervisa el documento; con Allow expired, la sesión nunca pasa a este estado.
- Sin transiciones automáticas. Un revisor, o
PATCH /v3/session/{sessionId}/update-status/, todavía puede cambiarla a"Approved","Declined"o"Resubmitted".
Transiciones de estado
Diagrama del ciclo de vida
Terminales vs. no terminales
Gestión de estados en tu código
Usa webhooks o la API de obtención de sesión para reaccionar a los cambios de estado.Reenvío
El estado Resubmitted permite a tu equipo de cumplimiento dar a los usuarios una segunda oportunidad sin crear una nueva sesión.1
El revisor inicia el reenvío
Desde la consola, abre una sesión
In Review o Declined y haz clic en Solicitar reenvío. Selecciona qué pasos deben rehacerse.2
Los datos anteriores se archivan
El sistema restablece las funciones seleccionadas y marca los datos anteriores como
previous_attempt, con lo que se conserva el registro de auditoría completo.3
Se notifica al usuario
Si hay una dirección de correo electrónico disponible, el usuario recibe un correo electrónico en su idioma con un enlace directo para continuar.
4
El usuario rehace pasos concretos
El usuario solo repite los pasos que se marcaron, no toda la verificación.
5
El sistema vuelve a evaluar
Una vez completado el proceso, la sesión pasa automáticamente a
"Approved", "Declined" o "In Review".Payload del webhook de reenvío
reasons asigna a cada node_id reenviado el código de advertencia del registro más relevante de ese paso (los mismos códigos que informa la decisión), para que puedas asociarlo a tus propios textos. También es el código que la pantalla de reenvío del flujo alojado y el correo de reenvío presentan al usuario en su idioma, excepto en las advertencias que revelarían una señal de análisis o de fraude (duplicados, AML, lista de bloqueo, comprobaciones entre organizaciones, integridad de la ubicación y similares): en esos casos, la persona ve un motivo genérico, y resubmit_info.reasons en tu webhook siempre contiene el código real. Un paso sin ninguna advertencia registrada no tiene entrada.
Qué funciones se pueden reenviar
Cualquier función con un estado no aprobado: Declined, In Review, Not Finished, Not Started o Expired.Buenas prácticas
Supervisa las sesiones en revisión
Configura alertas (por correo electrónico o Slack) en la consola de Didit para recibir avisos cuando haya sesiones que necesiten revisión manual.
Prioriza el reenvío
Si el problema tiene solución (foto borrosa, cara equivocada del documento), solicita un reenvío en lugar de rechazar la sesión. Así mejoras la tasa de conversión.
Haz seguimiento de los abandonos
Unas tasas altas de sesiones abandonadas o expiradas pueden indicar fricción en la experiencia de usuario. Plantéate ajustar el TTL de la sesión o mejorar las indicaciones al usuario.
Controladores idempotentes
Los webhooks pueden reintentarse. Usa
session_id como clave única para procesar cada cambio de estado una sola vez.