Saltar al contenido principal
Didit ofrece dos enfoques complementarios para la verificación de identidad. Entender en qué se diferencian es clave para elegir la integración adecuada a tu caso de uso.

​
Sesiones alojadas (recomendadas para flujos con el usuario presente)

Las sesiones alojadas son el enfoque recomendado para la mayoría de las integraciones. Cuando creas una sesión, Didit genera una verification_url que le presentas al usuario. El usuario completa todo el flujo de verificación en la interfaz optimizada de Didit, y tú recibes los resultados mediante webhook o API.

​
Cómo funciona

1

Crear la sesión

Tu servidor invoca POST /v3/session/ con el ID de un flujo de verificación (workflow). Didit devuelve una verification_url y un session_token.
2

Presentarla al usuario

Redirige al usuario, incrústala mediante un iframe o inicializa un SDK nativo con el token de sesión.
3

El usuario completa la verificación

El usuario sigue el flujo guiado en la interfaz optimizada de Didit: captura del documento de identidad, prueba de vida y cualquier paso adicional.
4

Recibir los resultados

Didit envía un webhook a tu servidor con la decisión de verificación, o bien consultas periódicamente la API de recuperación.

​
Por qué se recomiendan las sesiones

​
Cuándo usar sesiones

  • Onboarding de usuarios / KYC: nuevos usuarios se registran y necesitan verificar su identidad
  • Verificación de edad: confirma que los usuarios cumplen los requisitos de edad mínima
  • Reverificación: vuelve a verificar periódicamente a los usuarios existentes
  • Autenticación biométrica: los usuarios se autentican con su rostro para realizar acciones sensibles
  • Cumplimiento en varios pasos: flujos que requieren documento de identidad + Prueba de vida + AML + Teléfono de una sola vez
  • Cualquier escenario en el que el usuario final esté presente e interactúe directamente

​
Endpoints de sesión

​
API independientes (para procesamiento de servidor a servidor)

Las API independientes te permiten llamar a funciones de verificación concretas directamente desde tu servidor, sin ninguna interfaz para el usuario final. Envías los datos (imágenes, documentos, nombres) y recibes resultados estructurados.

​
Cómo funciona

1

Envía los datos

Tu servidor invoca un endpoint independiente (por ejemplo, POST /v3/id-verification/) con los datos necesarios: imágenes, documentos o campos JSON.
2

Recibe los resultados

Didit procesa la solicitud de forma síncrona y devuelve resultados de verificación estructurados en la respuesta.

​
Cuándo usar las API independientes

​
API independientes disponibles

Identidad y documentos Document AI Biometría y rostro Cumplimiento y riesgo Verificación bancaria Verificación de empresas (KYB)

​
Comparación lado a lado

​
Se pueden usar ambos

Sí. Muchos equipos combinan ambos enfoques:
  1. Sesiones para el onboarding: los nuevos usuarios completan todo el flujo de verificación alojado durante el registro
  2. AML independiente para la monitorización continua: una tarea cron vuelve a analizar cada noche a todos los usuarios aprobados frente a listas de vigilancia actualizadas
  3. Búsqueda facial independiente para detectar duplicados: cuando se aprueba una nueva sesión, tu servidor invoca la API de búsqueda facial para comprobar si hay duplicados
  4. Verificación de identidad independiente para operaciones: tu equipo de cumplimiento sube documentos manualmente para revisar casos límite

​
Ejemplo: arquitectura combinada

​
Primeros pasos

Última modificación el 1 de noviembre de 2026