Sesiones de Verificación
Una sesión representa una verificación de identidad. Al crearla se devuelve una widgetUrl que usted entrega a su cliente, y un sessionId que usa para correlacionar el resultado.
Crear una Sesión
Endpoint: POST /v1/sessions
Autenticación: token Bearer con el scope sessions
curl --request POST \
--url https://{FQDN}/v1/sessions \
--header "Authorization: Bearer $ACCESS_TOKEN" \
--header 'Content-Type: application/json' \
--data '{
"userRef": "user-123",
"language": "es",
"delivery": { "mode": "webhook" }
}'
{
"sessionId": "9f1c8e42-7c3e-4f2b-9d7a-2b1e5c8f4a10",
"status": "pending",
"widgetUrl": "https://{FQDN}/verify/8Kd2mQ…"
}
Campos de la Solicitud
| Campo | Tipo | Requerido | Descripción |
|---|---|---|---|
userRef | string (1-255) | Sí | Su identificador de la persona que se verifica. Se devuelve en cada resultado |
prefill | object | No | Datos conocidos sobre la persona — vea Prefill |
dataCheck | boolean | No | false (predeterminado) verifica el documento tal como se presenta. true además compara los datos extraídos contra prefill — vea Verificaciones de Datos |
delivery | object | No | Cómo le llega el resultado. El valor predeterminado es {"mode": "webhook"} |
language | string | No | Idioma del widget, xx o xx-XX (p. ej. en, pt, es, pt-BR). Recurre a su valor predeterminado configurado |
maxCaptureAttempts | integer (1-10) | No | Anula el valor predeterminado de su tenant solo para esta sesión |
Campos de la Respuesta
| Campo | Descripción |
|---|---|
sessionId | Úselo para correlacionar resultados y para llamar a GET /v1/sessions/{sessionId} |
status | Siempre pending al crearse |
widgetUrl | El enlace de cara al cliente. Contiene un código de un solo uso válido por 48 horas |
Prefill
prefill transporta lo que usted ya sabe sobre la persona. Tiene dos efectos distintos.
| Campo | Efecto |
|---|---|
documentType | passport, drivers_license o identity_card. Bloquea el widget a este documento — se omite la pantalla de selección de tipo, y un documento diferente es rechazado. Omítalo para dejar que el cliente elija |
documentNumber | Se valida su formato en esta llamada (vea abajo), y queda disponible para verificación cruzada |
issuingState | Código o nombre de estado de EE. UU. para licencias de conducir; país ISO 3166-1 alpha-3 para pasaportes y cédulas de identidad. Afina la validación de formato |
nationality | ISO 3166-1 alpha-3. Se usa para resolver la jurisdicción cuando issuingState está ausente |
firstName, lastName | Disponibles para verificación cruzada |
dateOfBirth | YYYY-MM-DD. Disponible para verificación cruzada |
{
"userRef": "user-123",
"prefill": {
"documentType": "drivers_license",
"issuingState": "PA",
"documentNumber": "31612967",
"firstName": "Ana",
"lastName": "Silva",
"dateOfBirth": "1988-03-04"
}
}
Los campos de prefill distintos de documentType no cambian la decisión a menos que configure dataCheck: true. Sin él, los valores se transportan para comparación y se reportan en el resultado, pero una discrepancia no enruta la sesión a ninguna parte.
Sin embargo, prefill.documentNumber sí se valida en esta llamada: un número que viola el formato conocido de su jurisdicción se rechaza con 422 en lugar de aceptarse y fallar después. Verifique un número antes de llegar aquí con el endpoint validador.
Verificaciones de Datos
Configure dataCheck: true para verificar que el documento pertenece a la persona que usted esperaba — no solo que el documento es genuino.
{
"userRef": "user-123",
"dataCheck": true,
"prefill": {
"firstName": "Ana",
"lastName": "Silva",
"dateOfBirth": "1988-03-04"
}
}
Con dataCheck: true:
- Los datos extraídos se comparan campo por campo contra el payload de prefill.
- El resultado incluye
prefillComparison(resultados por campo, incluidos puntajes de coincidencia difusa de nombres) yprefillMismatches(los nombres de los campos que discreparon). - Una discrepancia agrega una verificación blanda fallida, enrutando la sesión a
in_reviewen lugar de rechazarla.
Los nombres se comparan con coincidencia difusa contra un umbral de similitud configurable, de modo que las variaciones ordinarias de ortografía y transliteración no generan falsas discrepancias. dataCheck: true sin un payload de prefill es un 422 — no habría nada contra qué comparar.
Entrega
| Modo | Campos | Comportamiento |
|---|---|---|
webhook (predeterminado) | — | El resultado se envía vía POST a su webhookUrl configurada |
redirect | redirectUrl (requerido) | El cliente es devuelto a su URL con el resultado y una firma |
{ "delivery": { "mode": "redirect", "redirectUrl": "https://you.example/kyc-done" } }
Solicitar el modo webhook sin una webhookUrl configurada para su tenant es un 422. Consulte Recepción de Resultados para la verificación de firmas en ambos modos.
Respuestas de Error
Todas estas devuelven 422 con un detail que explica la causa específica:
| Causa | Notas |
|---|---|
delivery.mode es webhook pero no hay una webhookUrl configurada | Pida a Inyo registrar su endpoint, o use el modo redirect |
Falta delivery.redirectUrl en modo redirect | Requerido siempre que mode sea redirect |
documentType no está habilitado para su tenant | El mensaje lista los tipos de documento que puede solicitar |
| La jurisdicción emisora del documento no está aceptada para ese tipo de documento | El mensaje lista las jurisdicciones que usted acepta |
prefill.documentNumber falló la validación de formato | El mensaje nombra la regla que lo rechazó |
dataCheck: true sin payload de prefill | Proporcione al menos un campo de prefill comparable |
Las fallas de autenticación y autorización devuelven 401 o 403 — vea Autenticación.
Consultar una Sesión
Endpoint: GET /v1/sessions/{sessionId}
Autenticación: token Bearer con el scope sessions
Este es el registro autoritativo de una verificación. Consúltelo cuando necesite una garantía en lugar de un push, para conciliar un webhook que pudo haber perdido, o para leer el resultado de una sesión que fue a revisión manual.
curl --request GET \
--url https://{FQDN}/v1/sessions/$SESSION_ID \
--header "Authorization: Bearer $ACCESS_TOKEN"
{
"sessionId": "9f1c8e42-7c3e-4f2b-9d7a-2b1e5c8f4a10",
"userRef": "user-123",
"status": "in_review",
"step": "done",
"deliveryMode": "webhook",
"result": { "…": "the normalized result, updated in place" },
"createdAt": "2026-07-31T14:02:11.481Z",
"updatedAt": "2026-07-31T14:04:57.902Z"
}
| Campo | Descripción |
|---|---|
status | pending, approved, declined, in_review o expired |
step | Hasta dónde llegó el cliente: document_front, document_back, selfie o done |
deliveryMode | webhook, redirect o sync (una verificación servidor a servidor) |
result | El resultado normalizado completo una vez disponible, null antes de eso. Se actualiza en el mismo lugar cuando un analista decide |
Las sesiones están estrictamente limitadas al tenant. El sessionId de otro tenant devuelve 404 — nunca una divulgación parcial.
Próximos Pasos
- Validador de Número de Documento — verifique un número antes de llegar aquí
- Entrega del Widget — cómo guiar al cliente a través del flujo
- Recepción de Resultados — manejo de webhooks y redirecciones
