Saltar al contenido principal
GET
cURL

​
Compatibilidad con KYC y KYB

Este endpoint funciona tanto con sesiones de Verificación de usuario (KYC) como de Verificación de empresas (KYB). La respuesta siempre incluye un campo session_kind en el nivel superior:
  • "user": sesión de Verificación de usuario (KYC). La respuesta incluye id_verifications, liveness_checks, face_matches, nfc_verifications, poa_verifications y database_validations.
  • "business": sesión de Verificación de empresas (KYB). La respuesta incluye registry_checks, document_verifications y key_people_checks.
Ambos tipos comparten aml_screenings, phone_verifications, email_verifications, questionnaire_responses, ip_analyses, document_ai_documents, bank_verifications, reviews y contact_details, además de los campos comunes del nivel superior (session_id, session_number, session_url, status, workflow_id, vendor_data, metadata, callback, features, expected_details, created_at, expires_at). Didit busca el session_id en ambos tipos de sesión (primero en Verificación de usuario y después en Verificación de empresas) y devuelve la que coincida. Los UUID son únicos por aplicación, así que no hay ambigüedad. Consulta la descripción general de las sesiones para ver la matriz completa de funciones específicas de cada tipo.

​
Ejemplos

Respuesta (truncada):

​
Cómo gestionar la respuesta en tu sistema

​
Campos de estado, traza de la decisión y revisión

Cada decisión explica cómo se llegó a su status.

​
Retención de datos biométricos

biometric_retention siempre está presente. deletes_at es la fecha en que se eliminan los datos biométricos activos de la sesión, y jurisdictions enumera los estados de EE. UU. cuyas normas biométricas fijan un límite de eliminación para la persona (US cuando se desconoce el estado). deletes_at es null cuando todavía no es aplicable ninguna fecha.

​
Verificación de ubicación

Cuando el flujo tiene un paso de Verificación de ubicación, la decisión incluye dos arrays. geolocation_checks[] tiene un elemento por paso: su intento aceptado, con el resultado, las coordenadas y su precisión, las comprobaciones con la ubicación de la IP y con la dirección registrada, y las warnings del paso. geolocation_attempts[] enumera todos los intentos de todos los pasos, del más antiguo al más reciente, con el momento en que se recibió cada uno. Los flujos sin este paso devuelven ambos como null. Todos los campos y resultados se detallan en el Informe de verificación de ubicación.

​
Eventos de enrutamiento del flujo

?include=events añade la cronología de eventos de la sesión. Además de los cambios de paso y de estado, un flujo que enruta a través de nodos de rama deja un evento por cada decisión de enrutamiento, de modo que una integración (o la cronología de la Console) puede explicar por qué una sesión terminó con un resultado determinado sin tener que recorrer a mano el grafo del flujo: Ambos eventos incluyen sent_at en milisegundos, como cualquier otro evento, y no tienen component, feature_step ni step: los genera el motor de flujos, no el dispositivo del usuario. Una rama “else” (una rama sin condiciones) cuenta como rama coincidente; fallback solo es true cuando no coincidió nada. Los nodos con una sola arista de salida no toman ninguna decisión y no dejan ningún evento. La misma estructura también incluye workflow_terminal_node_id: el node_id del último nodo de estado del flujo registrado que estableció un estado de sesión, o null si no se ha registrado ningún ID de nodo de ese tipo. Es la procedencia histórica del flujo. Las aprobaciones, rechazos y reenvíos manuales no lo borran; un nodo de estado posterior del flujo lo reemplaza. Por ejemplo, si un flujo envía una sesión a un nodo En revisión y un revisor la aprueba después, el status actual es Approved, mientras que workflow_terminal_node_id sigue identificando el nodo En revisión. También puede seguir teniendo un valor mientras hay un reenvío en curso. Consulta el status actual y las cronologías de eventos y de activity_reviews para distinguir los resultados del flujo de las decisiones manuales posteriores.

​
Envíos anteriores (?include=resubmissions)

Un reenvío devuelve al usuario a los pasos que selecciones y conserva lo que esos pasos devolvieron antes. ?include=resubmissions añade un array resubmissions, del más antiguo al más reciente, con una entrada por cada solicitud de reenvío. Cada entrada contiene los resultados que esa solicitud reemplazó, de modo que siempre puedes consultar lo que el usuario envió antes. Funciona con sesiones de usuario (KYC) y de empresa (KYB), y puedes combinarlo con los eventos (?include=events,resubmissions). Sin el parámetro, la respuesta no cambia. Los resultados actuales (id_verifications y el resto en el nivel superior) siempre describen el envío más reciente. Los pasos a los que no se devolvió al usuario conservan ahí un único resultado.
Al eliminar una sesión se eliminan con ella los resultados de todos sus envíos.

​
Métodos de verificación de identidad

Cada elemento de id_verifications[] indica cuál de los tres métodos de verificación de identidad lo generó, para que puedas distinguir una lectura de documento de una consulta en un registro o de un inicio de sesión con wallet sin tener que deducirlo de los campos que resulten tener valor: Una sesión con documento informa document y documentary y deja el resto en null, por lo que las integraciones existentes no necesitan cambios. Los tipos de cada campo están en Modelos de datos.

​
Consentimiento biométrico

Las decisiones de Verificación de usuarios incluyen un objeto biometric_consent: si la sesión requería consentimiento biométrico explícito, el trigger que lo exigió, el status de la respuesta y su evidencia. Dos valores te indican que no se recogió el consentimiento: Cuándo aparece el paso y qué significa cada valor se explican en Consentimiento biométrico; todos los campos están en Modelos de datos.

​
Verificación bancaria

La verificación bancaria todavía no está habilitada en producción. Mientras no lo esté, un flujo de producción no puede incluir este paso y bank_verifications permanece en null.
Cuando el flujo tiene un paso de verificación bancaria, la decisión incluye bank_verifications[] en ambos tipos de sesión: un elemento por paso, con valor null hasta que un paso produzca un resultado. Lee method, no ownership.method, para distinguir el inicio de sesión en el banco de la comprobación de la cuenta: ownership.method es la comparación de nombres que produjo la puntuación. Todos los campos están en el esquema BankVerificationResult de la respuesta de este endpoint.

​
Firma electrónica

Cuando el flujo tiene un paso de firma electrónica, la decisión incluye signatures[] en ambos tipos de sesión. Contiene un elemento por firmante: uno para una verificación de usuario y uno por cada persona clave que firma en una verificación de empresas. Los flujos sin este paso no devuelven la clave en absoluto. Descarga los archivos desde esas rutas con tu clave de API. Consulta el informe de firma electrónica para ver todos los campos.

​
Errores

​
Páginas relacionadas

Autorizaciones

​
x-api-key
string
header
requerido

La clave de API de tu aplicación, que encontrarás en Developers -> API keys en la Business Console. La clave principal tiene acceso completo. Una clave con nombre puede tener un alcance limitado: ninguno, lectura o escritura por recurso, limitada a algunos flujos o a sesiones aprobadas, a una lista de direcciones IP y a una fecha de caducidad. 401 significa que la clave es incorrecta, se revocó o expiró; 403 significa que no se envió ninguna clave, que la clave no tiene acceso a este recurso o acción, o que la solicitud provino de una dirección fuera de su lista de IP; 404 en una ruta de sesión significa que la sesión está fuera de los flujos o estados de la clave. Una clave sin acceso a contenido multimedia recibe las URL de imágenes, videos y PDF como null, y una clave sin permiso de escritura en sesiones recibe los enlaces y tokens de sesión como null. Consulta https://docs.didit.me/console/api-keys.

Parámetros de ruta

​
sessionId
string<uuid>
requerido

UUID de la sesión de verificación cuya decisión quieres obtener. Es el session_id que devuelve POST /v3/session/. La misma ruta sirve para sesiones de Verificación de usuarios (KYC) y de Verificación de empresas (KYB): el servidor resuelve el ID en ambos tipos de sesión.

Debe ser un UUID válido. La ruta solo coincide con UUID bien formados, por lo que el enrutador de URL rechaza un valor mal formado antes de que se ejecute el código de la aplicación, y la respuesta es una página HTML 404 en lugar del envoltorio JSON {"detail": ...} que se muestra a continuación. Valida el formato del UUID en el cliente para poder distinguir un error de entrada de un 404 real por sesión inexistente.

Ejemplo:

"11111111-2222-3333-4444-555555555555"

Parámetros de consulta

​
include
enum<string>

Lista separada por comas de secciones adicionales del payload. Valores admitidos: events y resubmissions, por separado o juntos (events,resubmissions). Cuando se pasa include=events, la respuesta contiene además la cronología de eventos de la sesión (events, incluidos los eventos de enrutamiento WORKFLOW_BRANCH_EVALUATED / WORKFLOW_STATUS_NODE_REACHED descritos en la página Retrieve Session), el registro de actividad completo (activity_reviews), los indicadores de lista de bloqueo (blocklisted), un cost_breakdown por sesión, los metadatos del flujo (workflow_type, workflow_version, workflow_version_id y workflow_terminal_node_id: el último nodo de estado del flujo registrado que estableció un estado de sesión, o null si no se ha registrado ninguno; es una procedencia histórica que no se borra con aprobaciones, rechazos o reenvíos manuales, y que se reemplaza por un nodo de estado del flujo posterior) y los metadatos de la sesión (api_service: cadena o null, solo se establece en sesiones de API independiente; session_type: API, HOSTED o MIGRATED; has_device_nfc_support: booleano). Dos campos cambian respecto a la estructura simple: el discriminador de nivel superior session_kind se omite (la estructura con eventos solo existe para sesiones de usuario), y el array features pasa de cadenas simples a objetos {feature, node_id}, donde la función de correo electrónico se indica como EMAIL en lugar de EMAIL_VERIFICATION. Esta estructura ampliada la usa principalmente la Didit Console; la mayoría de las integraciones de API deberían omitir el parámetro. Limitación de KYB: include=events solo se aplica a sesiones de usuario (KYC). Las sesiones de empresa (session_kind = "business") siempre devuelven la estructura estándar de decisión de empresa: events, activity_reviews, blocklisted, cost_breakdown y los metadatos adicionales workflow_* y de sesión nunca se devuelven para sesiones de empresa, y su array features sigue siendo un array de cadenas simples. Con include=resubmissions (tanto en sesiones de usuario como de empresa), la respuesta también contiene resubmissions: una entrada por cada solicitud de reenvío, de la más antigua a la más reciente, cada una con number, created_at, previous_status, nodes, reasons, requested_by y results (lo que devolvieron los pasos reenviados antes de la solicitud, con las mismas claves y la misma estructura que los resultados actuales). Cada elemento de cost_breakdown incluye usage_type, price, details y created_at: un paso reenviado que se vuelve a ejecutar se factura como un elemento nuevo.

Opciones disponibles:
events,
resubmissions,
events,resubmissions
Ejemplo:

"events"

Respuesta

Informe de decisión completo. session_kind distingue las dos estructuras: las sesiones user incluyen los arrays de funciones KYC que se muestran abajo; las sesiones business, en cambio, incluyen registry_checks, document_verifications y key_people_checks junto con los arrays compartidos. Los arrays de funciones son null hasta que el flujo ha ejecutado esa función; las URL de los archivos multimedia son enlaces prefirmados de corta duración.

​
session_id
string<uuid>

El identificador único de la sesión.

​
session_kind
enum<string>

Discriminador que indica si se trata de una sesión de Verificación de usuarios (KYC) o de Verificación de empresas (KYB). Cuando es user, se aplican los arrays de funciones KYC (id_verifications, nfc_verifications, liveness_checks, face_matches, poa_verifications, document_ai_documents, database_validations, ...) y los arrays de empresa no aparecen. Cuando es business, el payload incluye en su lugar registry_checks, document_verifications, key_people_checks además de los arrays compartidos (aml_screenings, phone_verifications, email_verifications, ip_analyses, questionnaire_responses). Se omite cuando se pasa include=events: la estructura de eventos solo existe para sesiones de usuario, por lo que el discriminador se elimina de esa variante.

Opciones disponibles:
user,
business
​
shared_from_session
string<uuid> | null

En una sesión clonada con POST /v3/session/import-shared/: el session_id de la sesión original en la aplicación de origen. null en cualquier otra sesión. Se omite cuando se pasa include=events.

​
shared_from_session_number
integer | null

session_number de la sesión de origen cuando esta sesión se importó desde otra aplicación de tu organización. null en caso contrario.

​
session_number
integer | null

El número de la sesión.

​
session_url
string<uri> | null

La URL de la sesión.

​
status
enum<string>

Estado global del ciclo de vida de la sesión: el resultado consolidado del flujo. Los valores finales son Approved, Declined, In Review, Expired, Kyc Expired y Abandoned; Not Started, In Progress, Awaiting User y Resubmitted indican que la sesión sigue avanzando por el flujo.

Opciones disponibles:
Not Started,
In Progress,
Awaiting User,
In Review,
Approved,
Declined,
Resubmitted,
Expired,
Kyc Expired,
Abandoned
​
status_override
object | null

Presente cuando un revisor estableció status manualmente. null cuando el estado es el automático. Úsalo para distinguir una aprobación manual de una automática.

​
decision_trace
object

Cómo se llegó al estado: quién lo estableció y qué advertencias lo provocaron.

​
linked_records
object | null

Un resumen de otros registros vinculados a la sesión. null cuando no hay nada que mostrar, y en los flujos que declaran un estándar de verificación de edad.

​
workflow_id
string<uuid> | null

Identificador estable del grupo de flujos que generó esta sesión. Los flujos tienen versiones: este valor identifica el flujo en sí, no una versión concreta.

​
features
string[]

Lista de funciones de verificación configuradas para esta sesión, como nombres para mostrar: ID_VERIFICATION, NFC, LIVENESS, FACE_MATCH, POA, PHONE, EMAIL_VERIFICATION, AML, IP_ANALYSIS, DATABASE_VALIDATION, QUESTIONNAIRE, AGE_ESTIMATION, FACE_SEARCH, GEOLOCATION (verificación de ubicación) (las sesiones de Verificación de empresas usan el conjunto de funciones KYB: KYB_REGISTRY, KYB_DOCUMENTS, KYB_KEY_PEOPLE, AML, PHONE, EMAIL_VERIFICATION, IP_ANALYSIS, QUESTIONNAIRE). Con include=events, cada entrada pasa a ser un objeto {feature, node_id} en lugar de una cadena simple, y la función de correo electrónico cambia de nombre: aparece como EMAIL en el modo de eventos en lugar del EMAIL_VERIFICATION que se usa aquí.

La función de la sesión.

​
vendor_data
string | null

Los datos del proveedor de la sesión.

​
metadata
object | null

Los metadatos de la sesión.

​
expected_details
object | null

Datos esperados que se proporcionan al crear la sesión: se usan para la validación cruzada con los datos extraídos (KYC) o para rellenar previamente la búsqueda en el registro de empresas (KYB). Devuelve exactamente las claves que se proporcionaron; null cuando no se proporcionó ninguna. Las sesiones KYC incluyen los campos de la persona; las sesiones de empresa (KYB) incluyen company_name, registry_country y registration_number.

​
contact_details
object | null

Datos de contacto proporcionados al crear la sesión (se usan para los correos electrónicos de notificación, la verificación de teléfono o correo electrónico prellenada y el idioma de comunicación). null cuando no se proporcionó ni un correo electrónico ni un número de teléfono.

​
callback
string<uri> | null

La URL de callback de la sesión.

​
id_verifications
object[] | null

Array de informes de verificación de identidad (OCR) generados por los pasos de documento de identidad del grafo del flujo. Siempre es un array JSON: lee id_verifications[0] e itera si tu flujo puede ejecutar más de una verificación de identidad (por ejemplo, una verificación principal más una verificación reforzada). Es null hasta que al menos un paso de identidad haya generado datos. Cada elemento es el informe completo, que incluye node_id, el status a nivel de función, los campos extraídos del documento, las URL de las imágenes, las puntuaciones de calidad, la MRZ, el análisis de la dirección, las coincidencias entre sesiones y warnings[].

​
nfc_skip_reason
enum<string> | null

Por qué no se ejecutó la verificación del chip NFC; se rellena siempre que el flujo incluye un paso NFC. null mientras NFC está pendiente o cuando el chip sí se leyó. Valores: USER_SKIPPED: el usuario decidió omitirlo en un dispositivo compatible con NFC (permitido por allow_nfc_skip); DOCUMENT_WITHOUT_CHIP: el documento no tiene un chip NFC legible (no es un documento electrónico ICAO 9303); CHIP_CERTIFICATE_UNAVAILABLE: el certificado de firma del país emisor (CSCA) que cubre el periodo de emisión del documento no está disponible, por lo que no se puede verificar la firma del chip; DEVICE_WITHOUT_NFC: el dispositivo indicó que no tiene lector NFC; INTEGRATION_WITHOUT_NFC_ACCESS: la verificación se ejecutó sin un SDK nativo (por ejemplo, en un navegador web), que no tiene acceso al lector NFC del teléfono; MRZ_KEY_UNAVAILABLE: no se pudo obtener la clave de acceso al chip a partir de la MRZ del documento; JPKI_UNAVAILABLE: el documento es una My Number Card de Japón, cuyo chip se lee mediante JPKI, y JPKI no estaba disponible para esta verificación: no está habilitado o el SDK nativo de la aplicación no puede leer My Number Cards.

Opciones disponibles:
USER_SKIPPED,
DOCUMENT_WITHOUT_CHIP,
CHIP_CERTIFICATE_UNAVAILABLE,
DEVICE_WITHOUT_NFC,
INTEGRATION_WITHOUT_NFC_ACCESS,
MRZ_KEY_UNAVAILABLE,
JPKI_UNAVAILABLE
​
nfc_verifications
object[] | null

Array de informes NFC / ePassport generados por los pasos NFC del grafo del flujo. Siempre es un array JSON, nunca un objeto nfc singular: lee nfc_verifications[0] e itera si tu flujo puede ejecutar NFC más de una vez. Es null hasta que al menos un paso NFC haya generado datos. Cada elemento es el informe completo, que incluye node_id, el status a nivel de función, chip_protocol, chip_data, authenticity (integridad de SOD + DG), certificate_summary y warnings[]. Una My Number Card de Japón se lee mediante JPKI en lugar de ICAO 9303: su elemento tiene chip_protocol: "jpki", incluye su evidencia en jpki y deja los campos ICAO en null. Cuando el paso NFC se omitió antes de poder ofrecerse (documento sin chip, certificado ausente, sin capacidad NFC informada, clave MRZ ilegible, JPKI no disponible para una My Number Card), este campo permanece en null y nfc_skip_reason explica el motivo; una omisión en el propio paso (el usuario pulsó omitir o el lector resultó no estar disponible en el momento del escaneo) sigue generando un informe con is_nfc_skipped: true.

​
liveness_checks
object[] | null

Array de informes de prueba de vida generados por los pasos de prueba de vida del grafo del flujo. Siempre es un array JSON, nunca un objeto liveness singular. Es null hasta que al menos un paso de prueba de vida haya generado datos. Cada elemento es el informe completo, que incluye node_id, el status a nivel de función, method, score, reference_image, video_url, age_estimation opcional, matches[] entre sesiones y warnings[].

​
face_matches
object[] | null

Array de informes de coincidencia facial generados por los pasos de coincidencia facial del grafo del flujo. Siempre es un array JSON, nunca un objeto face_match singular. Es null hasta que al menos un paso de coincidencia facial haya generado datos. Cada elemento es el informe completo, que incluye node_id, el status a nivel de función, el score de similitud, source_image, target_image y warnings[].

​
phone_verifications
object[] | null

Array de informes de verificación de teléfono: siempre es un array JSON, nunca un objeto phone singular. Es null hasta que al menos un paso de teléfono haya generado datos. Cada elemento es el informe completo, que incluye node_id, el status a nivel de función, el número de teléfono y los metadatos del país, lifecycle[], matches[] y warnings[].

​
email_verifications
object[] | null

Array de informes de verificación de correo electrónico: siempre es un array JSON, nunca un objeto email singular. Es null hasta que al menos un paso de correo electrónico haya generado datos. Cada elemento es el informe completo, que incluye node_id, el status a nivel de función, la dirección de correo electrónico, los datos de filtraciones, lifecycle[], matches[] y warnings[].

​
poa_verifications
object[] | null

Array de informes de Prueba de domicilio (POA): siempre es un array JSON, nunca un objeto poa singular. Es null hasta que al menos un paso de POA haya generado datos. Cada elemento es el informe completo, que incluye node_id, el status a nivel de función, la URL del archivo del documento, el emisor, las fechas, la dirección analizada y warnings[].

​
document_ai_documents
object[] | null

Informes de Document AI agrupados por nodo del flujo: siempre es un array JSON, nunca un objeto individual. Vale null hasta que al menos un paso de Document AI haya generado datos. Solo está presente cuando session_kind = user. Cada elemento es un grupo de nodo con un status agregado, el node_id, un array items[] con los resultados de cada documento (datos extraídos indexados por la clave de campo configurada) y warnings.

​
questionnaire_responses
object[] | null

Array de informes de respuestas de cuestionarios: siempre es un array JSON, nunca un objeto questionnaire singular. Es null hasta que al menos un paso de cuestionario haya generado datos. Cada elemento es el informe completo, que incluye node_id, los metadatos del cuestionario, las secciones con elementos de formulario y las respuestas del usuario.

​
bank_verifications
object[] | null

Resultados de Verificación bancaria, un elemento por cada paso de Verificación bancaria, para Verificación de usuarios y Verificación de empresas. null hasta que un paso produzca uno. El method de cada elemento indica cómo se verificó la cuenta: open_banking (inicio de sesión en el banco) o account_lookup (comprobación de la cuenta), o una alternativa statement o microdeposits, y none cuando la persona continuó sin banco antes de que se evaluara algún intento (continued_without_bank). Consulta Métodos de verificación bancaria. La Verificación bancaria aún no está habilitada en producción, por lo que este campo sigue siendo null en las sesiones de producción hasta que lo esté.

​
signatures
object[]

Resultados de la firma electrónica, un elemento por firmante y paso de firma, para la Verificación de usuarios y la Verificación de empresas. Solo está presente cuando el flujo tiene un paso de Firma electrónica; es un array vacío hasta que un firmante llega a él. Consulta el informe de firma electrónica.

​
aml_screenings
object[] | null

Array de informes de análisis AML: siempre es un array JSON, nunca un objeto aml singular. Es null hasta que al menos un paso de AML haya generado datos. Cada elemento es el informe completo, que incluye node_id, el status a nivel de función, total_hits, entity_type, hits[], score, screened_data, is_ongoing_monitoring_enabled y warnings[].

​
ip_analyses
object[] | null

Array de informes de Análisis de dispositivo e IP: siempre es un array JSON, nunca un objeto ip_analysis singular. Es null hasta que al menos un paso de análisis de IP haya generado datos. Cada elemento es el informe completo, que incluye node_id, el status a nivel de función, los datos de IP y geolocalización, la huella digital del dispositivo y warnings[]. Las entradas con (node_id, ip_address, device_fingerprint) duplicados se deduplican en el servidor.

​
geolocation_checks
object[] | null

Array de resultados de verificación de ubicación, uno por cada paso de verificación de ubicación: el intento aceptado de ese paso. Es null hasta que un paso de verificación de ubicación haya generado datos. Los intentos anteriores del mismo paso están en geolocation_attempts.

​
geolocation_attempts
object[] | null

Todos los intentos de cada paso de verificación de ubicación de esta sesión, del más antiguo al más reciente. Se omiten los intentos sustituidos por un reenvío. Un flujo de verificación (workflow) que oculta geolocation_checks mediante sus atributos de respuesta también oculta esta lista.

​
database_validations
object[] | null

Array de informes de Validación de base de datos: siempre es un array JSON, nunca un objeto database_validation singular. Vale null hasta que al menos un paso de validación de base de datos haya generado datos. Cada elemento es el informe completo, que incluye node_id, el status a nivel de función, screened_data, las validations[] por servicio (cada una con su source_data del registro) y warnings[]. Los campos screened_data y source_data varían según el país:

ARG (Argentina): screened_data: {document_number, selfie, gender, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, date_of_death, tax_id, tax_id_type, face_match_score, sit_1_since, banks, last_position, highest_position, rejected_checks}. Usa la validación biométrica de coincidencia facial de RENAPER. El género se infiere automáticamente a partir del análisis facial o del nombre de pila cuando no figura en el documento (por ejemplo, en licencias de conducir)

BOL (Bolivia): screened_data: {document_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, gender}

BRA (Brasil): screened_data: {tax_number, first_name, last_name, date_of_birth}. source_data siempre incluye {identification_number, first_name, last_name, date_of_birth, lgpd_minor, minor_under_18, minor_under_16} en las coincidencias de CPF correctas. Las consultas exitosas de adultos establecen esos indicadores en false. El servicio Consulta CPF de la Receita Federal puede devolver HTTP 422 (menor de 18 años) o 451 (menor de 16 años) con datos retenidos por la LGPD; en esos casos, source_data establece los indicadores de menor en true según corresponda, incluye el estado HTTP de origen y la validación a nivel de campo es no_match. Consulta la sección de Brasil de la referencia de códigos de resultado de Validación de base de datos para ver la lista completa de códigos.

CHL (Chile): screened_data: {personal_number, first_name, last_name, date_of_birth}. source_data: {identification_number, first_name, last_name, date_of_birth, gender}

COL (Colombia): screened_data: {document_number, document_type, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, document_type}

CRI (Costa Rica): screened_data: {personal_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

DOM (República Dominicana): screened_data: {personal_number}. source_data: {identification_number} (solo devuelve válido/no válido)

ECU (Ecuador): screened_data: {personal_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, street, formatted_address, gender, nationality, education, marital_status, spouse, mother_name, father_name, profession}

ESP (España): screened_data: {personal_number, document_type, expiration_date, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, document_type, expiration_date}

GTM (Guatemala): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

HND (Honduras): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

MEX (México): screened_data: {personal_number (CURP), first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, gender, nationality, curp_status, state_of_birth, doc_probatorio, registration_year, registration_state, registration_municipality, num_acta, crip, issuing_state_code, foreign_registry_number, folio_carta, folio_certificado}. Usa el registro civil de RENAPO. Para MEX también está disponible un servicio independiente de comprobación de vigencia del INE como validación adicional individual.

PAN (Panamá): screened_data: {personal_number, selfie}. source_data: {identification_number}. Usa la validación biométrica de SIB

PER (Perú): screened_data: {personal_number (DNI), first_name, last_name}. source_data: {identification_number, first_name, last_name, paternal_name, maternal_name, verification_number, verification_letter}

PRY (Paraguay): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

SLV (El Salvador): screened_data: {document_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

URY (Uruguay): screened_data: {personal_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

VEN (Venezuela): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, gender, date_of_birth, document_type}

​
database_validation_not_performed_reason
object | null

Por qué una validación de base de datos configurada no produjo ningún resultado, como {code, message} más campos de contexto. Solo está presente cuando database_validations es null en un flujo que tiene el paso, para que puedas distinguir entre "el registro coincidió" y "no se ejecutó nada". null en caso contrario.

​
reviews
object[]
​
assignee
object | null

El revisor de la consola al que está asignada la sesión, o null cuando nadie la tiene asignada.

​
waiting_since
string<date-time> | null

Fecha y hora en que la sesión empezó a esperar revisión. null salvo que la sesión esté en In Review y tu aplicación configure un plazo de revisión.

​
sla_due_at
string<date-time> | null

Fecha límite de la revisión. null salvo que la sesión esté en In Review y tu aplicación configure un plazo de revisión.

​
created_at
string<date-time>

Marca de tiempo en la que se creó la sesión (ISO 8601, UTC).

​
expires_at
string<date-time> | null

Marca de tiempo en la que está previsto que expire esta sesión. Se establece en las sesiones de Verificación de usuarios (KYC) cuando se configuró una expiración al crearlas (o cuando el estado Approved desencadena el cálculo de la expiración del KYC). null en las sesiones sin una expiración configurada y en los tipos que no usan expiración (p. ej., las sesiones de Verificación de empresas (KYB) que nunca recibieron un expires_at).

​
registry_checks
object[] | null

Comprobaciones en el registro de empresas. Solo está presente cuando session_kind = business. Cada elemento incluye el payload completo del registro de empresas.

​
key_people_checks
object[] | null

Comprobaciones agregadas de las personas clave. Solo están presentes cuando session_kind = business. Cada elemento usa la estructura de dos grupos (registry, submitted, ubo_kyc_summary).

​
document_verifications
object[] | null

Comprobaciones de verificación de documentos agrupadas por nodo del flujo. Solo aparece cuando session_kind = business.

​
environment
enum<string>

Si la sesión la creó una aplicación de producción (live) o una aplicación de sandbox (sandbox). Las sesiones de sandbox son gratuitas, totalmente simuladas y nunca consumen créditos.

Opciones disponibles:
live,
sandbox
​
sandbox_scenario
string | null

El escenario de sandbox con el que se creó la sesión. null para las sesiones en producción y para las sesiones de sandbox creadas sin escenario.

​
resubmissions
object[]

Solo se devuelve con include=resubmissions, para sesiones de usuarios y de empresas. Una entrada por cada solicitud de reenvío, de la más antigua a la más reciente. Cada entrada contiene los resultados que devolvieron los pasos reenviados antes de la solicitud, de modo que los envíos anteriores siguen siendo legibles. Al eliminar la sesión se eliminan todos los envíos.

​
biometric_consent
object | null

Si la sesión exigió un consentimiento biométrico explícito antes de una captura facial, el motivo y la evidencia de la respuesta. Solo para sesiones de Verificación de usuarios (KYC); el mismo objeto está en la decision de los webhooks de sesión. null cuando la sesión nunca se evaluó, por ejemplo, en un flujo sin captura facial. Los campos sin valor registrado son null. Un SDK nativo anterior a la 4.10.0, o uno que no informa su versión, no puede mostrar el paso de consentimiento: sus capturas faciales se ejecutan como antes, y una sesión que exigía consentimiento informa entonces status: "pending" con reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK". Consulta Consentimiento biométrico.

​
investigator
object | null

La revisión más reciente del elemento en Investigator, o null si nunca tuvo una. La incluyen la decisión de sesión V3 y la decisión de sesión de empresa (y, por tanto, los webhooks status.updated).

​
biometric_retention
object

Fecha y hora en que se eliminan los datos biométricos en vivo de esta sesión.

​
fraud_check
object | null

El resultado de una llamada a la Fraud Check API. null para cualquier otra sesión.

​
full_session_video
string<uri> | null

URL temporal de la grabación de la sesión completa. Solo se devuelve cuando tu organización graba vídeo de la sesión completa.

​
full_session_video_recorded_at
string<date-time> | null

Cuándo se realizó la grabación de la sesión completa. Solo se devuelve cuando tu organización graba vídeo de la sesión completa.

Última modificación el 1 de noviembre de 2026