Overview
Face Search emits a small set of warnings so your team can tell why a search returnedApproved 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 suppressesPOSSIBLE_DUPLICATED_FACE— you never get both members of a pair for the same confidence band. additional_datareferences the first matching face only, even whenmatches[]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_DETECTEDcarriesnull. Theapi_servicevalue is uppercase (e.g.PASSIVE_LIVENESS) ornullfor 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 inuser_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_similarranks every enrolled face by similarity;blocklisted_or_approvedrestricts candidates to blocklisted faces, allowlisted faces, faces from approved sessions, and imported user-profile faces, ranking blocklisted entries first.save_api_request(defaulttrue) — 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 tofalseto query without storing or enrolling.rotate_image(defaultfalse) — 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)
Related
- Face Search report — full response shape
- Face Search API reference — request parameters
- Face Match warnings — 1:1 selfie-to-document warnings (separate from Face Search)
- Data models — Face Search — canonical schema