Saltar al contenido principal
En esta guía se explica el flujo completo para integrar la verificación de identidad de Didit mediante la API REST: obtener las credenciales, crear una sesión, presentarla al usuario y recibir los resultados.

Paso 1: Obtén tus credenciales

Tienes dos formas de obtener una api_key:

Opción A: Registro programático (sin navegador)

Es la mejor opción para CI/CD y agentes de IA. Dos llamadas a la API, POST /programmatic/register/ y después POST /programmatic/verify-email/, devuelven la api_key directamente en la respuesta. → Consulta Registro programático para ver el flujo completo, las reglas de contraseñas, la duración del JWT y la política de bloqueo.

Opción B: Desde la Didit Console

  1. Ve a la Didit Console.
  2. Crea o selecciona tu organización.
  3. Ve a Settings → API & Webhooks.
  4. Copia:
    • API Key: se usa como encabezado x-api-key en cada llamada de verificación.
    • Webhook Secret Key: se usa para verificar las firmas HMAC de los webhooks.

Variables de entorno


Paso 2: Crea un flujo de verificación (workflow)

Antes de crear sesiones, necesitas un flujo de verificación. Los flujos definen los pasos de verificación que siguen los usuarios.

Créalo en la Console

  1. Ve a la Didit Console → Workflows
  2. Haz clic en Create Workflow
  3. Elige una plantilla base:
  1. Añade funciones opcionales:
  1. Copia tu Workflow ID
Consulta la documentación de flujos para ver las opciones de configuración en detalle.

Paso 3: Crea una sesión de verificación

Llama a la API para crear una sesión para tu usuario.

Solicitud

Parámetros de la solicitud

Ejemplo completo con todas las opciones

expected_details.expected_document_types restringe el paso de verificación de identidad a tipos de documento concretos: la pantalla de selección de documento solo muestra los tipos solicitados. Valores permitidos: P (pasaporte), ID (documento nacional de identidad), DL (licencia de conducir), RP (permiso de residencia), HIC (tarjeta de seguro médico), TC (tarjeta fiscal), SSC (tarjeta de seguridad social). Los valores no distinguen entre mayúsculas y minúsculas y se eliminan los duplicados; los valores desconocidos devuelven 400. Consulta la referencia de Create Session para ver el esquema completo.

Respuesta

201 Created:

Campos clave de la respuesta

Idempotencia. Cuando se proporciona vendor_data y ya existe una sesión sin terminar (Not Started, In Progress, Resubmitted o Awaiting User) con el mismo vendor_data en la última versión publicada del flujo, se devuelve esa sesión existente (igualmente con 201) en lugar de crear un duplicado, con su callback y su metadata actualizados a los nuevos valores, y con un status que refleja el de la sesión existente.
Si falta x-api-key, se devuelve 403 con {"detail": "You do not have permission to perform this action."}, el mismo cuerpo que con una clave válida sin permiso. Una clave incorrecta, revocada o expirada devuelve 401. Si los créditos son insuficientes, se devuelve 400. Consulta la referencia de la API de Create Session para ver la documentación completa.

Paso 4: Presenta la verificación al usuario

Elige cómo presentar el flujo de verificación a tu usuario:

Opción A: SDK nativo (recomendado para móvil)

Usa el session_token con los SDK nativos para integrar la cámara, NFC y la biometría. → SDK de iOS · SDK de Android · React Native · Flutter

Opción B: iframe InContext (recomendado para web)

Inserta la verificación en tu página con la url devuelta en el paso 3.
→ iframe InContext

Opción C: Redirección

Redirige al usuario a la URL de verificación.
→ Redirección web

Opción D: WebView móvil

Para aplicaciones móviles sin SDK nativo.
→ WebView en iOS/Android

Paso 5: Recibe los resultados

Mediante webhook (recomendado)

Los webhooks notifican a tu servidor en tiempo real cuando cambia el estado de una verificación. Configuración:
  1. Crea un destino de webhook en la Console (API y Webhooks) o mediante POST /v3/webhook/destinations/ con webhook_version: "v3" y un array subscribed_events (por ejemplo, ["status.updated"])
  2. Guarda el secret_shared_key que se devuelve al crearlo: es el secreto HMAC de todas las variantes de firma
  3. Implementa un endpoint de webhook en tu servidor
Ejemplo de payload de webhook: Dentro de decision, cada resultado por función se entrega como un array en plural (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], …), con una entrada por cada nodo del flujo. Este es el contrato de V3 y es intocable: nunca programes contra una clave en singular como nfc / id_verification / liveness.
El objeto decision solo está presente cuando status es Approved, Declined, In Review o Abandoned (un evento Resubmitted incluye resubmit_info en su lugar). Didit reutiliza el mismo event_id en los reintentos y en el envío a varios destinos, así que basa tu idempotencia en él. Consulta Modelos de datos para ver cada array en plural y cada campo. Verifica la firma (X-Signature-V2, recomendado): X-Signature-V2 es un HMAC-SHA256 calculado sobre una recodificación canónica del cuerpo JSON: los números de punto flotante con valor entero se reducen a enteros, las claves se ordenan de forma recursiva, se usan separadores compactos y se conserva Unicode.
→ Documentación completa de webhooks, que incluye la firma X-Signature sobre los bytes sin procesar, la firma obsoleta X-Signature-Simple, que solo firma el envoltorio, y cómo elegir entre ellas. Didit reintenta las entregas fallidas (5xx, 404, tiempo de espera agotado) hasta 2 veces (a los ~1 min y luego a los ~4 min) y el tiempo de espera es de 5 segundos, así que devuelve un 2xx rápidamente.

Mediante la API (opcional)

Obtén el mismo payload de decisión en cualquier momento:
La estructura de la respuesta (arrays en plural) es idéntica a la del objeto decision del payload del webhook, y el endpoint se puede llamar en cualquier momento del ciclo de vida de la sesión. Usa webhooks para las actualizaciones en tiempo real y reserva las llamadas a la API para completar datos faltantes, auditorías y reconstrucciones: el endpoint /decision/ tiene un límite de 600 solicitudes GET por minuto por clave de API (consulta Límites de solicitudes). Semántica de errores: un session_id desconocido devuelve 404 con {"detail": "Not found."}; los fallos de autenticación se devuelven como 403, y este endpoint nunca devuelve 401. Las URL de medios de la respuesta son enlaces prefirmados de corta duración: descárgalos cuanto antes en lugar de almacenarlos. → Referencia de la API para obtener la sesión

Ejemplos de código completos

Node.js / Express

Python / FastAPI


Estados de la sesión

Estos son los 10 valores posibles de status, como cadenas exactas que distinguen mayúsculas de minúsculas (ten en cuenta que Kyc Expired lleva una sola K mayúscula): Consulta Estados de verificación para ver el ciclo de vida completo, las transiciones y el diagrama Mermaid.

Próximos pasos

  1. Elige tu método de integración:
  2. Configura los webhooks: Webhooks
  3. Planifica la capacidad: Límites de solicitudes
  4. Gestiona todos los estados: Estados de verificación
  5. Personaliza tu flujo de trabajo: Flujos de trabajo
  6. Comprueba que la API está accesible: Healthcheck

Necesitas ayuda

Última modificación el 1 de noviembre de 2026