Saltar al contenido principal
Las sesiones son la unidad de verificación en Didit. Cuando inicias una verificación, se crea una sesión; cuando la verificación termina, la sesión contiene el payload completo de la decisión. La misma API de sesiones gestiona ambos tipos: En la lección de Academy sobre lo que ven los usuarios, el capítulo del minuto 5:34 compara el flujo alojado con crear tus propias pantallas, que es justo la disyuntiva que esta API resuelve por ti.

​
El tipo lo determina el flujo de verificación

Cuando creas una sesión, pasas un workflow_id. El tipo del flujo de verificación (workflow) determina si la sesión es de Verificación de usuario o de Verificación de empresas; quien hace la llamada no lo elige por separado. Los flujos KYB crean sesiones de Verificación de empresas; los flujos KYC crean sesiones de Verificación de usuario.

​
Discriminador session_kind

Toda respuesta de sesión (de creación, consulta, listado, actualización de estado, compartición e importación) incluye un campo de nivel superior:
  • "user": la sesión es una sesión de Verificación de usuario (KYC). La respuesta contiene arrays de funciones específicos de usuario.
  • "business": la sesión es una sesión de Verificación de empresas (KYB). La respuesta contiene arrays de funciones específicos de empresa.
Usa este campo para decidir qué estructura procesar en tu aplicación.
Los valores del enum son los identificadores cortos "user" y "business"; los mantenemos cortos por ergonomía de la API. En toda la documentación se usan los nombres completos Verificación de usuario (KYC) y Verificación de empresas (KYB) para mayor claridad.

​
Arrays de funciones por tipo

Los arrays de funciones presentes en una decisión dependen del tipo. Los campos que no existen en un tipo simplemente no aparecen en esa respuesta (sin nulos ni marcadores de posición):

​
Campos de nivel superior compartidos

Toda sesión (de ambos tipos) incluye estos campos:

​
Endpoints incluidos

Todos los endpoints siguientes aceptan cualquiera de los dos tipos. No hay rutas /v3/business-session/* separadas.

​
Cómo funcionan las búsquedas

Las sesiones de Verificación de usuario y de Verificación de empresas son dos tipos distintos. Los ID son UUID, por lo que las colisiones son imposibles. Cuando llamas a un endpoint con un session_id, Didit:
  1. Busca primero el ID en la tabla de Verificación de usuario (que cubre la mayor parte del tráfico).
  2. Si no lo encuentra, recurre a la tabla de Verificación de empresas.
  3. Devuelve 404 si no hay coincidencia en ninguna de las dos tablas.
Nunca necesitas indicarle a la API qué tipo estás buscando.

​
Los estados son idénticos

Los valores de estado son los mismos para ambos tipos, y la API los devuelve exactamente como se escriben aquí: "Not Started", "In Progress", "Approved", "Declined", "In Review", "Abandoned", "Expired", "Kyc Expired", "Resubmitted", "Awaiting User". La coincidencia es exacta y distingue entre mayúsculas y minúsculas. Consulta los estados de verificación para ver la referencia completa.

​
Webhooks

Los eventos de webhook ya incluyen un campo session_kind para que tus manejadores de webhook puedan procesar cada evento según su tipo: Consulta webhooks para la verificación de firma y la semántica de reintentos, y webhooks de KYB para el catálogo de eventos de Verificación de empresas (KYB).

​
Próximos pasos

Crear sesión

Inicia una verificación: Verificación de usuarios o Verificación de empresas.

Obtener sesión

Obtén la decisión. Funciona con ambos tipos.

Listar sesiones

Filtra por session_kind.

Actualizar estado

Aprueba, rechaza, envía a revisión o solicita un nuevo envío.

Generar PDF

Informes PDF por tipo.

Compartir + importar

Mueve sesiones entre aplicaciones.
Última modificación el 1 de noviembre de 2026