Saltar al contenido principal

Descripción general

Cada informe por función sigue la estructura del serializador V3 definida en service-didit-verification. El mismo objeto aparece en tres lugares, así que el esquema que ves aquí es la única fuente de verdad para todos ellos:
  • GET /v3/session/{sessionId}/decision/: cada función se devuelve como un array con nombre en plural (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], poa_verifications[], phone_verifications[], email_verifications[], aml_screenings[], ip_analyses[], database_validations[], questionnaire_responses[], signatures[], bank_verifications[] (consulta Métodos de verificación bancaria) y los equivalentes de KYB registry_checks[], document_verifications[], key_people_checks[]).
  • Payloads de webhook (status.updated, data.updated): la misma estructura dentro del envoltorio decision.
  • APIs independientes: las respuestas de un solo objeto (Búsqueda facial, Estimación de edad, Autenticación biométrica) reutilizan el mismo conjunto de campos.
V3 introdujo los flujos de trabajo multiinstancia: cada objeto de función incluye un node_id que vincula el informe al nodo del grafo del flujo que lo generó. Los endpoints V2 (en singular: kyc, face, aml, etc.) siguen siendo retrocompatibles, pero solo devuelven la primera instancia.

Campos comunes

Cada objeto de informe expone lo siguiente: Los campos multimedia (portrait_image, front_image, document_file, …) son URLs prefirmadas con un periodo de validez limitado: descárgalos cuanto antes en lugar de guardar la URL. Los ejemplos los muestran como https://<media-host>/....

Objeto de advertencia

Se devuelve en cada array warnings[]. Esquema de logs/serializers/log.py:8-65 (LogV3Serializer).

Objetos de informe

Las secciones restantes describen cada objeto de informe por función. El texto de los encabezados H3 se mantiene estable a propósito para que otros documentos puedan enlazarlos directamente.

Verificación de identidad

Se devuelve por cada documento de KYC/identidad que envía un usuario. Aparece como id_verifications[] en GET /v3/session/{sessionId}/decision/ y dentro del campo kyc de las respuestas V2. Fuente: kyc/serializers/kyc.py:383-414 (IDVerificationV3Serializer, que extiende IDVerificationV2Serializer en kyc/serializers/kyc.py:320-380).
El mismo objeto con un método distinto del documento. Solo cambian las claves específicas del método: todo lo que completa la lectura de un documento se rellena, en su lugar, a partir del registro oficial o de los atributos de la wallet, y las claves que no aplican son null.

Verificación NFC

Se devuelve por cada lectura de chip de un documento de identidad: un chip de ePassport o eID conforme a ICAO 9303, o una tarjeta My Number de Japón leída mediante JPKI (chip_protocol: "jpki"). Aparece como nfc_verifications[] en GET /v3/session/{sessionId}/decision/ (uno por cada registro KYC principal). Fuente: kyc/serializers/epassport.py:121-139 (NFCV3Serializer, que extiende NFCV2Serializer en kyc/serializers/epassport.py:83-118).

Prueba de vida

Se devuelve por cada sesión de prueba de vida. Aparece como liveness_checks[] en GET /v3/session/{sessionId}/decision/. Fuente: face/serializers/face.py:301-320 (LivenessV3Serializer, extiende LivenessV2Serializer en face/serializers/face.py:216-298).

Coincidencia facial

Se devuelve por cada comparación de coincidencia facial (normalmente, el rostro del usuario en la prueba de vida frente al retrato del documento). Aparece como face_matches[] en GET /v3/session/{sessionId}/decision/. Fuente: face/serializers/face.py:367-389 (FaceMatchV3Serializer, extiende FaceMatchV2Serializer en face/serializers/face.py:323-364).

Búsqueda facial

Lo devuelve la API independiente de Búsqueda facial (POST /v3/face-search/). La Búsqueda facial nunca aparece como un array en plural en /v3/session/{sessionId}/decision/: cuando se guarda con save_api_request=true, la sesión aparece ahí como una entrada FACE_SEARCH en features[] más un elemento de liveness_checks[] que contiene los matches almacenados. Fuentes: apis/serializers/face_search.py:8-79 (FaceSearchResponseSerializer, que envuelve FaceSearchDetailsSerializer); los diccionarios de coincidencias se construyen en face/utils/utils.py:869-884. Respuesta de nivel superior: Objeto face_search:

Objeto de coincidencia de búsqueda facial

Análisis AML

Se devuelve por cada entidad analizada. Aparece como aml_screenings[] en GET /v3/session/{sessionId}/decision/ tanto en sesiones KYC como KYB. Fuente: aml/serializers/aml.py:63-85 (AMLV3Serializer, que extiende AMLV2Serializer en aml/serializers/aml.py:28-60).

Análisis de IP

Se devuelve por cada ubicación de red capturada. Aparece como ip_analyses[] en GET /v3/session/{sessionId}/decision/ tanto en sesiones KYC como KYB. Fuente: kyc/serializers/location.py:196-243 (IPAnalysisSerializerV3).

Verificación de ubicación

Se devuelve por cada paso de Verificación de ubicación. Aparece como geolocation_checks[] en GET /v3/session/{sessionId}/decision/: un elemento por paso, con su intento aceptado. geolocation_attempts[] enumera todos los intentos de todos los pasos, del más antiguo al más reciente. Ambos son null en un flujo sin este paso. Fuente: GeolocationDecisionSerializer. Todos los campos y ejemplos están en el informe de verificación de ubicación.

Prueba de domicilio

Se devuelve por cada documento de domicilio enviado. Aparece como poa_verifications[] en GET /v3/session/{sessionId}/decision/. Fuente: poa/serializers/poa.py:212-227 (POAV3Serializer, que extiende POAV2Serializer en poa/serializers/poa.py:173-209).

Verificación de teléfono

Se devuelve por cada intento de verificación de teléfono. Aparece como phone_verifications[] en GET /v3/session/{sessionId}/decision/ tanto en sesiones de KYC como de KYB. Fuente: phone/serializers/phone.py:251-266 (PhoneV3Serializer, extiende PhoneV2Serializer en phone/serializers/phone.py:103-248).

Verificación de correo electrónico

Se devuelve por cada intento de verificación de correo electrónico. Aparece como email_verifications[] en GET /v3/session/{sessionId}/decision/ tanto en sesiones de KYC como de KYB. Fuente: email_verification/serializers/email.py:149-164 (EmailV3Serializer, extiende EmailV2Serializer en email_verification/serializers/email.py:38-146).

Validación de base de datos

Se devuelve por cada consulta a base de datos realizada con los datos enviados por el usuario. Aparece como database_validations[] en GET /v3/session/{sessionId}/decision/. Fuente: database_validation/serializers/database_validation.py:21-142 (DatabaseValidationV3Serializer, extiende DatabaseValidationV2Serializer).

Respuesta de cuestionario

Se devuelve por cada envío de cuestionario. Aparece como questionnaire_responses[] en GET /v3/session/{sessionId}/decision/ tanto en sesiones KYC como KYB. Origen: questionnaires/serializers/questionnaire.py:591-597 (QuestionnaireResponseV3Serializer, que extiende QuestionnaireResponseSerializer en questionnaires/serializers/questionnaire.py:520-588).

Firma electrónica

Se devuelve por cada firmante de un paso de Firma electrónica. Aparece como signatures[] en GET /v3/session/{sessionId}/decision/ tanto en sesiones KYC como KYB, solo cuando el flujo incluye ese paso. A diferencia de los demás objetos de informe, su status es la etapa de firma y su resultado está en verdict, y los elementos de su warnings[] son { code, node_id } en lugar de objetos de advertencia. El informe de firma electrónica incluye un ejemplo completo y todos los campos anidados.

Estimación de edad

Lo devuelve la API independiente de Estimación de edad (POST /v3/age-estimation/). La respuesta contiene un subconjunto de la estructura de Liveness check dentro de un envoltorio age_estimation (status, method, score, age_estimation, warnings), además de un bloque user_image de detección facial exclusivo de la API independiente; no incluye reference_image, video_url, matches, face_quality ni face_luminance. En las sesiones de un flujo no hay un array separado: la edad estimada aparece como liveness_checks[].age_estimation en GET /v3/session/{sessionId}/decision/. Fuente: apis/serializers/age_estimation.py:50-55 (AgeEstimationResponseSerializer), con el envoltorio construido en apis/views/age_estimation.py:138-174.

Autenticación biométrica

La autenticación biométrica ejecuta el mismo pipeline de prueba de vida + coincidencia facial que se usa en el KYC estándar, pero configurado para comparar el rostro capturado con la imagen de referencia de un usuario existente en lugar de con el retrato de un documento recién procesado por OCR. No hay un serializer dedicado: GET /v3/session/{sessionId}/decision/ devuelve los objetos estándar Liveness check y Face match en liveness_checks[] y face_matches[]. El flujo de la sesión se configura con workflow_type = "biometric_authentication" (WorkflowTypeChoices, common/config/choices.py:636).

Registro KYB

Se devuelve por cada empresa confirmada en el registro dentro de un flujo de verificación (workflow) KYB. Aparece como registry_checks[] en GET /v3/session/{sessionId}/decision/ para las sesiones de empresa. Fuente: kyb/serializers/kyb.py:939-964 (RegistryCheckV3Serializer).

Objeto de empresa

Procede de kyb/serializers/kyb.py:220-321 (KYBCompanyResponseSerializer).

Documento KYB

Se devuelve por cada nodo que recopila documentos justificativos de KYB. Aparece como document_verifications[] en GET /v3/session/{sessionId}/decision/ para las sesiones de empresa: una entrada por cada node_id, con items[] que enumera cada documento subido. Fuente: kyb/serializers/kyb.py:1053-1068 (DocumentVerificationV3Serializer); cada elemento sigue kyb/serializers/kyb.py:811-851 (KYBDocumentResponseSerializer).

Objeto de elemento de documento KYB

Persona clave de KYB

Se devuelve por cada nodo de Personas clave de un flujo KYB. Aparece como key_people_checks[] en GET /v3/session/{sessionId}/decision/ para las sesiones de empresas. Fuente: kyb/serializers/kyb.py:967-1050 (KeyPeopleCheckV3Serializer).

Campos a nivel de decisión

Estas claves están junto a los arrays de cada función en GET /v3/session/{sessionId}/decision/ y dentro del objeto decision de un webhook. Consulta Obtener una sesión para saber cómo leerlos.

Consentimiento biométrico

Cada decisión y webhook de sesión de Verificación de usuarios incluye un único objeto biometric_consent (no un array): si la sesión requería consentimiento biométrico explícito, por qué y la evidencia de la respuesta. Es null cuando la sesión nunca se evaluó, por ejemplo en un flujo de verificación (workflow) sin captura facial. Origen: BiometricConsentDecisionSerializer (sessions/serializers/biometric_consent.py). Cuándo aparece el paso y qué significa cada caso se explica en Consentimiento biométrico. Los campos sin valor registrado son null, nunca una cadena vacía. Una sesión en Illinois realizada mediante un SDK nativo anterior a 4.10.0, que capturó la selfie sin el paso:
Una persona en una VPN con salida fuera de EE. UU., que aceptó en el flujo alojado:

Referencia de los valores de estado

Dos conjuntos de valores relacionados comparten el nombre de campo status. Todos los objetos de informe por función de esta página usan el enum de nivel de función; el status de nivel superior de la sesión principal usa el enum de sesión, más amplio.

Estados de nivel de función

Los usa el campo status de todos los objetos de informe. Origen: common/config/choices.py:343-348 (FeatureStatusChoices). La verificación de teléfono, la de correo electrónico y la de identidad también pueden devolver Expired cuando se agota el tiempo de su paso (PhoneStatusChoices en common/config/choices.py:377-382, EmailStatusChoices en common/config/choices.py:434-439).

Estados de nivel de sesión

Los usa el status de nivel superior de la sesión principal. Origen: common/config/choices.py:106-117 (StatusChoices).
Los valores finales de sesión son Approved, Declined, In Review, Expired, Kyc Expired y Abandoned. Una sesión puede alcanzar su decisión global mientras una función concreta sigue en In Review.
Última modificación el 1 de noviembre de 2026