Skip to main content

Overview

Face Search emits a small set of warnings so your team can tell why a search returned Approved or Declined. Warnings are returned in the face_search.warnings[] array of the POST /v3/face-search/ response (see Face Search report). Warnings here use a reduced shape compared with workflow warnings: there is no node_id. The documented response contract declares five fields — risk, additional_data, log_type, short_description, long_description — and the runtime payload additionally carries feature, which is always "LIVENESS" on this endpoint.

Warnings produced

Producer: FaceSearchAPIView.add_warnings (apis/views/face_search.py:250-330); status derivation: get_face_search_status (apis/views/face_search.py:242-248), which declines only for the two blocklist risks. Emission rules worth knowing:
  • Blocklist takes precedence over duplicates. A confirmed blocklist hit suppresses DUPLICATED_FACE, and a possible blocklist hit suppresses POSSIBLE_DUPLICATED_FACE — you never get both members of a pair for the same confidence band.
  • additional_data references the first matching face only, even when matches[] contains several. Blocklist warnings carry {blocklisted_session_id, blocklisted_session_number, api_service}; duplicate warnings carry {duplicated_session_id, duplicated_session_number, api_service}; MULTIPLE_FACES_DETECTED carries null. The api_service value is uppercase (e.g. PASSIVE_LIVENESS) or null for workflow sessions.
  • Allowlisted faces suppress duplicate warnings — a high-confidence allowlist match clears DUPLICATED_FACE/POSSIBLE_DUPLICATED_FACE (it never clears blocklist warnings).

Exact warning strings

Search-image gate

When no face is detected in user_image, the API rejects the request with HTTP 400 and {"error": "No face detected in the image"} before a face_search object is built — so a NO_FACE_DETECTED warning never appears in a successful Face Search response. This is returned as a top-level error string, not in warnings[].

Configurable settings

The similarity bands that split confirmed hits (FACE_IN_BLOCKLIST, DUPLICATED_FACE) from possible hits (POSSIBLE_FACE_IN_BLOCKLIST, POSSIBLE_DUPLICATED_FACE) are fixed internally — per-application threshold tuning applies to the workflow liveness check, not this endpoint. The switches you control per request are:
  • search_type (most_similar, default | blocklisted_or_approved) — most_similar ranks every enrolled face by similarity; blocklisted_or_approved restricts candidates to blocklisted faces, allowlisted faces, faces from approved sessions, and imported user-profile faces, ranking blocklisted entries first.
  • save_api_request (default true) — persists the call as an API-type session and enrolls the searched face into your face search index. Faces enrolled by Face Search calls are excluded from future Face Search results. Set to false to query without storing or enrolling.
  • rotate_image (default false) — tries 90-degree rotations and keeps the orientation with the best face detection; useful when EXIF orientation is missing.

Examples

Blocklist hit (forces Declined)

Duplicate signal (status stays Approved)

Warning types