Saltar al contenido principal

Descripción general

El informe de prueba de vida recoge todo lo que Didit observó al verificar que había una persona real y viva frente a la cámara, y no una foto impresa, una reproducción en pantalla o un deepfake. Incluye el método de prueba de vida, una puntuación de confianza de 0 a 100, la selfie de referencia y el video de captura, una estimación de edad opcional, métricas de calidad de la prueba de vida pasiva y las coincidencias faciales entre sesiones con el historial y la lista de bloqueo de tu aplicación. El informe se genera cuando el usuario completa el paso de prueba de vida en un flujo de verificación (workflow) o cuando invoca el endpoint facial independiente. Didit ejecuta uno de los tres métodos de prueba de vida (3D activa, con destellos o pasiva), puntúa la captura, busca patrones de suplantación conocidos y compara biométricamente el rostro con todos los demás rostros que hayas registrado en tu aplicación. Cada informe tiene su propio status, independiente del estado general de la sesión, que refleja cómo se resolvió únicamente el paso de prueba de vida:
  • Aprobado: se detectó un rostro, la puntuación de prueba de vida supera el umbral de revisión y no se activó ninguna advertencia de rechazo automático.
  • En Revisión: se activaron una o más advertencias configuradas para enviarse a revisión, o la puntuación es igual o inferior al umbral de revisión pero superior al umbral de rechazo.
  • Rechazado: se cumplió una condición de rechazo automático (NO_FACE_DETECTED, LIVENESS_FACE_ATTACK, FACE_IN_BLOCKLIST o los riesgos de edad en los flujos de estimación de edad), una advertencia configurable se envió a rechazo, o la puntuación es igual o inferior al umbral de rechazo.
  • No finalizado: el usuario nunca completó el paso de prueba de vida.

Dónde aparece en las respuestas de la API

El informe de prueba de vida aparece como liveness_checks[] en GET /v3/session/{sessionId}/decision/. Siempre es un array JSON, nunca un objeto liveness singular. Aparecen varias entradas cuando un flujo ejecuta la prueba de vida más de una vez (por ejemplo, una comprobación principal más una nueva captura).
  • API de decisión de sesión: GET /v3/session/{sessionId}/decision/ devuelve liveness_checks[] en el nivel superior. Consulta Obtener la decisión de la sesión.
  • Webhooks: los payloads de session.status.updated incluyen el mismo array liveness_checks[] una vez que el paso ha generado datos. Consulta Webhooks.
  • API independiente de prueba de vida: consulta API independiente de prueba de vida.
Lee response.liveness_checks[0] y recorre el array: la estructura singular liveness a la que hacían referencia algunos tutoriales antiguos no existe en el endpoint de decisión v3.

Esquema

El esquema canónico campo por campo está en la página de referencia Modelos de datos. Los campos de abajo reflejan ese esquema canónico.

Coincidencias faciales entre sesiones

matches[] enumera los rostros del historial de tu aplicación que superaron el umbral de similitud biométrica frente a este selfie: hasta 5 entradas, primero los rostros de la lista de bloqueo y de la lista de permitidos, y después por similitud descendente. Los candidatos elegibles son los rostros de la lista de bloqueo, los rostros de la lista de permitidos, los rostros de sesiones Approved y los rostros importados para tus usuarios del proveedor. Los rostros que pertenecen al mismo usuario (mismo vendor_data, o el mismo usuario de proveedor cuando está disponible) se excluyen de toda la búsqueda, tanto de la detección de duplicados como del análisis contra la lista de bloqueo. Cada entrada incluye:

Valores de estado

Los estados proceden del enum compartido de estados de función (FeatureStatusChoices).

Ejemplos

Approved: captura 3D activa sin incidencias

In Review: prueba de vida pasiva, captura de baja calidad y un posible duplicado

Aquí la calidad del rostro (12.4) está por debajo del umbral de revisión predeterminado (15), la luminancia (18.7) está por debajo del mínimo predeterminado (20) y la acción del flujo para rostros duplicados está configurada en Review, así que las tres advertencias llevan log_type: "warning" y el informe queda en In Review.

Nota de seguridad

Los videos y selfies de prueba de vida son datos biométricos: las URL firmadas son temporales y caducan (después de 4 horas de forma predeterminada). Trátalas como recursos de corta duración: no las almacenes en caché ni las expongas públicamente. Normalmente tu aplicación solo necesita status, score y las advertencias; guarda lo mínimo posible para reducir los datos biométricos en tus servidores.

Relacionado

Última modificación el 1 de noviembre de 2026