Saltar al contenido principal

Descripción general

Búsqueda facial es una búsqueda biométrica 1:N: Didit toma el rostro detectado más grande de tu user_image y lo busca en el índice de búsqueda facial de tu aplicación. Ese índice contiene los rostros registrados a partir de sesiones de verificación, llamadas independientes a la API guardadas, rostros subidos directamente a perfiles de usuario y tus listas de bloqueo y de permitidos. Se diferencia de Coincidencia facial, que es 1:1: Coincidencia facial compara una selfie con el retrato de un documento concreto, mientras que Búsqueda facial responde a la pregunta “¿hemos visto a esta persona antes en algún lugar?”. Conviene entender dos comportamientos antes de analizar el informe:
  • Solo las coincidencias con la lista de bloqueo provocan un rechazo. face_search.status es Declined solo cuando se dispara una advertencia FACE_IN_BLOCKLIST o POSSIBLE_FACE_IN_BLOCKLIST. Las coincidencias duplicadas por sí solas devuelven Approved, así que revisa matches y warnings, no solo status.
  • Persistencia y registro opcionales. Cuando save_api_request=true (el valor predeterminado), la llamada se guarda como una sesión de tipo API y el rostro buscado se registra en tu índice de búsqueda facial. Los rostros registrados mediante llamadas a Búsqueda facial se excluyen de los resultados de futuras búsquedas faciales, de modo que las búsquedas repetidas nunca coinciden entre sí. Pasa save_api_request=false para hacer una consulta puntual: no se almacena nada y el rostro no se registra.

Dónde aparecen los resultados

Face Search es una API independiente. Los resultados de la búsqueda se devuelven de forma síncrona y solo en la respuesta de POST /v3/face-search/, como un único objeto face_search en el nivel superior:
No existe ningún array plural face_searches[]. La convención de arrays en plural que usan id_verifications[], aml_screenings[] y liveness_checks[] en el endpoint de decisión de sesión no se aplica aquí. Cuando save_api_request=true (el valor predeterminado), la llamada también se guarda como una sesión de tipo API:
  • Business Console: la sesión aparece en tu lista de sesiones con la imagen de búsqueda, las coincidencias y las advertencias.
  • GET /v3/session/{sessionId}/decision/: puedes recuperarla usando el request_id devuelto como id de sesión. Los datos guardados aparecen como una entrada FACE_SEARCH en features[] y como un elemento de liveness_checks[] que contiene los matches almacenados (con valores de match_image_url recién firmados) y las warnings, no como un objeto face_search.
Cuando save_api_request=false, request_id es un UUID de correlación transitorio: la sesión nunca se almacena, por lo que no se puede consultar desde la Consola ni desde el endpoint de decisión.

Esquema

Consulta Búsqueda facial en la referencia de modelos de datos para ver las tablas de campos canónicas. La estructura siguiente refleja lo que el endpoint devuelve realmente en tiempo de ejecución.
Notas sobre los campos:
  • matches[] tiene un máximo de 5 entradas por encima del umbral mínimo de similitud, ordenadas por similitud descendente (search_type=blocklisted_or_approved coloca primero las entradas de la lista de bloqueo, después las de la lista de permitidos y luego ordena por similitud).
  • source indica de dónde se registró el rostro coincidente: session es una sesión de verificación o una invocación guardada de la API independiente; imported es un rostro subido directamente a un perfil de usuario; list_entry es un rostro asociado a una de tus listas; retained_template es una plantilla biométrica sin imagen que la aplicación conservó tras eliminar la sesión de origen. session_id, session_number, status y api_service son null en las coincidencias imported, list_entry y retained_template.
  • Las coincidencias retained_template incluyen vendor_user_id, vendor_data y biometric_template_id, y siempre tienen null en match_image_url, user_details y todo lo relacionado con la sesión: la sesión que generó el rostro ya no existe y la plantilla no contiene ninguna imagen ni datos de identidad. is_blocklisted es siempre false en una plantilla conservada; un rostro de la lista de bloqueo se informa por separado como una coincidencia list_entry. Elimina la plantilla con DELETE /v3/biometric-templates/{biometric_template_id}/.
  • api_service es el tipo de API independiente de la sesión coincidente (en mayúsculas, por ejemplo PASSIVE_LIVENESS) y es null cuando el rostro coincidente procede de una sesión de verificación de un flujo de trabajo normal.
  • user_details procede de la verificación de documento de la sesión coincidente. En las coincidencias source: imported se rellena con los datos del perfil de usuario (full_name definido, document_type/document_number nulos); es null cuando no existen datos de identidad (por ejemplo, en sesiones solo de prueba de vida).
  • Las advertencias usan una estructura reducida en comparación con las advertencias de los flujos: no incluyen node_id. El contrato de respuesta documentado (FaceSearchResponseSerializer) declara cinco campos: risk, additional_data, log_type, short_description y long_description. El payload en tiempo de ejecución incluye además feature, que aquí siempre es "LIVENESS". Consulta Advertencias de Búsqueda facial.
  • Las coincidencias del mismo usuario no se excluyen. A diferencia de la detección de duplicados de los flujos, el endpoint independiente no filtra las sesiones anteriores con el mismo vendor_data, por lo que un usuario legítimo que vuelve coincide con sus propias sesiones anteriores.

Valores de estado

El face_search.status de nivel superior se deriva de warnings[]. El status de cada coincidencia refleja el resultado de verificación de la sesión coincidente y es independiente. Nota: cuando la imagen de búsqueda no contiene ningún rostro detectable, la API devuelve HTTP 400 con {"error": "No face detected in the image"} antes de construir un objeto face_search, así que no existe un estado Declined para ese caso. Si no hay créditos suficientes, se devuelve HTTP 403 antes de procesar cualquier imagen.

Ejemplos

Aprobada: coincidencia duplicada, sin lista de bloqueo

Rechazada: coincidencia con la lista de bloqueo

Relacionado

Cuando save_api_request=true, los valores de match_image_url son URL firmadas de corta duración: vuelve a consultar el endpoint de decisión de la sesión con el request_id devuelto para obtener otras nuevas. Cuando save_api_request=false, son rutas de almacenamiento interno y no se pueden descargar directamente. Guarda en tu sistema solo el id de la sesión coincidente, el estado y similarity_percentage; no conserves la imagen biométrica subyacente.
Última modificación el 1 de noviembre de 2026