Skip to main content
The Biometric Authentication report is how Didit reports back a returning-user re-verification. The workflow runs a fresh liveness check and, when Face Match is enabled in the workflow, a 1:1 face match against the reference face resolved at session creation (the portrait_image you supplied, or the user’s stored face looked up by vendor_data). Both checks appear as standard feature items in the V3 session decision response.
Didit biometric authentication report combining liveness check and face match against a stored portrait

Overview

Biometric Authentication is a workflow type (workflow_type: "biometric_authentication"), not a separate response object. When the workflow runs it emits:
  • One liveness check that captures a live selfie and scores it for spoofing.
  • One face match comparing the captured face against the reference face resolved at session creation (only when Face Match is enabled in the workflow).
Whenever the workflow includes Face Match, session creation needs a reference face. Send portrait_image (base64-encoded image, max 2MB), or omit it and Didit reuses the face already stored for the vendor_data user: an approved liveness face first, then the ePassport chip photo, then the ID document portrait, then a manually enrolled profile face. If neither portrait_image nor a stored face is available, session creation returns 400 with {"portrait_image": "No stored face image was found for this user. Send a portrait_image, or complete an approved verification with face liveness or an ID document for this vendor_data first."}. In both cases the resolved reference is recorded under the new session, so the face-match item’s source_image_session_id is set to that session’s own session_id (it tells you the reference came from the session’s stored portrait rather than from a document portrait captured in the same session, which would leave the field null).

Where it appears

Both arrays are returned by GET /v3/session/{sessionId}/decision/ for sessions whose workflow type is biometric_authentication. They are always arrays — never singular objects — and each is null until its step has produced data. Each item carries a node_id so that multi-instance workflows can disambiguate steps.

Schema reference

The full field list is defined once on the data-models page so every report that surfaces these features shares one source of truth:
  • Liveness item schemastatus, method, score, reference_image, video_url, age_estimation, matches[], face_quality, face_luminance, warnings[], node_id.
  • Face match item schemastatus, score, source_image_session_id, source_image, target_image, warnings[], node_id.
  • Warning entry shapefeature, risk, additional_data, log_type, short_description, long_description, node_id.

Status values

Both liveness_checks[].status and face_matches[].status use the shared feature lifecycle (feature-level statuses): The overall session status aggregates both items: any feature in Declined declines the session, any in In Review puts the session in In Review, otherwise Approved (after every feature finishes). For threshold behavior and the full list of warning codes, see Biometric Authentication warnings.

Example — liveness + face match (approved)

Examples are abridged: the full decision envelope also carries session_url, metadata, callback, reviews, contact_details, expected_details, environment, created_at, and expires_at.

Example — liveness-only (Face Match disabled in the workflow)

Liveness-only mode is a workflow configuration: when Face Match is disabled, no reference face is needed at session creation and face_matches stays null. When Face Match is enabled, omitting portrait_image does not fall back to liveness-only: Didit reuses the face stored for the vendor_data user, and if no stored face exists session creation fails with 400.

Example — face-match declined on low similarity

Security note

reference_image, video_url, source_image, and target_image are signed URLs that expire after a limited validity window (4 hours by default). They point at biometric data — do not cache or surface them publicly. Store the verification result (status, score, source_image_session_id) on your side; re-fetch the decision endpoint if you need fresh URLs.

Biometric Auth warnings

Warning codes, thresholds, and automatic decline conditions.

Liveness report

Full field reference for liveness_checks[] items.

Face Match report

Full field reference for face_matches[] items.