Inyo

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

CampoTipoRequeridoDescripción
userRefstring (1-255)Su identificador de la persona que se verifica. Se devuelve en cada resultado
prefillobjectNoDatos conocidos sobre la persona — vea Prefill
dataCheckbooleanNofalse (predeterminado) verifica el documento tal como se presenta. true además compara los datos extraídos contra prefill — vea Verificaciones de Datos
deliveryobjectNoCómo le llega el resultado. El valor predeterminado es {"mode": "webhook"}
languagestringNoIdioma del widget, xx o xx-XX (p. ej. en, pt, es, pt-BR). Recurre a su valor predeterminado configurado
maxCaptureAttemptsinteger (1-10)NoAnula el valor predeterminado de su tenant solo para esta sesión. Se aplica por tipo de captura — este número de intentos de documento y el mismo de selfie

Campos de la Respuesta

CampoDescripción
sessionIdÚselo para correlacionar resultados y para llamar a GET /v1/sessions/{sessionId}
statusSiempre pending al crearse
widgetUrlEl 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.

CampoEfecto
documentTypepassport, 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
documentNumberSe valida su formato en esta llamada (vea abajo), y queda disponible para verificación cruzada
issuingStateSolo la subdivisión — código o nombre de estado de EE. UU. Afina la validación de formato de una licencia. No es un país: los pasaportes y cédulas de identidad no evidencian subdivisión, así que un alpha-3 enviado aquí todavía resuelve la jurisdicción, pero nunca se compara con el documento. Nombre el país en issuingCountry
issuingCountryISO 3166-1 alpha-3, un nombre de país o un alias común. Nombra el país emisor directamente — una licencia no lo lleva en su cara, así que sin esto una licencia no estadounidense se verifica contra las tablas de EE. UU.
nationalityISO 3166-1 alpha-3. Se usa para resolver la jurisdicción cuando issuingState está ausente. Nunca se usa para una licencia — la nacionalidad no es emisión
firstName, lastNameDisponibles para verificación cruzada
dateOfBirthYYYY-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 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) y prefillMismatches (los nombres de los campos que discreparon).
  • Una discrepancia agrega una verificación document_data_match fallida y se reporta en el resultado.

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

ModoCamposComportamiento
webhook (predeterminado)El resultado se envía vía POST a su webhookUrl configurada
redirectredirectUrl (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 errorCode: "validation_error"; errors[] nombra el campo y la causa:

CausaNotas
delivery.mode es webhook pero no hay una webhookUrl configuradaPida a Inyo registrar su endpoint, o use el modo redirect
Falta delivery.redirectUrl en modo redirectRequerido siempre que mode sea redirect
documentType no está habilitado para su tenantEl mensaje lista los tipos de documento que puede solicitar
La jurisdicción emisora del documento no está aceptada para ese tipo de documentoEl mensaje lista las jurisdicciones que usted acepta
prefill.documentNumber falló la validación de formatoEl mensaje nombra la regla que lo rechazó
dataCheck: true sin payload de prefillProporcione 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 sesión de widget. Léalo cuando necesite una garantía en lugar de un push, para recuperar un webhook que pudo haber perdido, o para leer el resultado de una sesión que fue a revisión manual.

Una verificación creada con POST /v1/verifications no se sirve aquí — tiene una lectura propia en GET /v1/verifications/{verificationId}, accesible con el scope verifications. Pasar una de ellas aquí devuelve 404.

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": "completed",
  "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"
}
CampoDescripción
statuspending, completed o failed — la posición en el ciclo de vida, nunca un veredicto. El resultado, cuando lo recibe, es result.decision
stepHasta dónde llegó el cliente: document_front, document_back, selfie o done
deliveryModewebhook o redirect — cómo le llega el desenlace de esta sesión, elegido al crearla
resultEl 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