Overview
The liveness report captures everything Didit observed while verifying that a real, live person was in front of the camera — not a printed photo, screen replay, or deepfake. It includes the liveness method, a 0–100 confidence score, the reference selfie and capture video, an optional age estimate, passive-liveness quality metrics, and cross-session face matches against your application’s history and blocklist. The report is produced after the user completes the liveness step in a workflow (or hits the standalone face endpoint). Didit runs one of three liveness methods (active 3D, flashing, or passive), scores the capture, screens for known spoof patterns, and compares the face biometrically against every other face you’ve seen in your application. Each report carries its ownstatus — independent of the overall session status — that reflects how the liveness step alone resolved:
- Approved — face detected, liveness score above the review threshold, no auto-decline warning fired.
- In Review — one or more warnings routed to review fired, or the score is at or below the review threshold but above the decline threshold.
- Declined — an auto-decline condition fired (
NO_FACE_DETECTED,LIVENESS_FACE_ATTACK,FACE_IN_BLOCKLIST, or the age risks on age-estimation flows), a configurable warning was routed to decline, or the score is at or below the decline threshold. - Not Finished — the user never completed the liveness step.
Where it appears in API responses
The liveness report appears asliveness_checks[] in GET /v3/session/{sessionId}/decision/ — always a JSON array, never a singular liveness object. Multiple entries appear when a workflow runs liveness more than once (for example a primary check plus a re-capture).
- Session decision API —
GET /v3/session/{sessionId}/decision/returnsliveness_checks[]at the top level. See Retrieve session decision. - Webhooks —
session.status.updatedpayloads include the sameliveness_checks[]array once the step has produced data. See Webhooks. - Standalone liveness API — see Liveness standalone API.
Read
response.liveness_checks[0] and iterate the array — the singular liveness shape some older tutorials referenced does not exist on the v3 decision endpoint.Schema
The canonical field-by-field schema lives on the Data models reference page. The fields below mirror that canonical schema.Cross-session face matches
matches[] lists the faces in your application’s history that exceeded the biometric similarity threshold against this selfie — up to 5 entries, blocklisted and allowlisted faces first, then by descending similarity. Eligible candidates are blocklisted faces, allowlisted faces, faces from Approved sessions, and faces imported against your vendor users. Faces belonging to the same user (same vendor_data, or the same vendor-user when available) are excluded from the entire search — both duplicate detection and blocklist screening.
Each entry includes:
Status values
Statuses come from the shared feature-status enum (FeatureStatusChoices).
Examples
Approved — clean active-3D capture
In Review — passive liveness, low-quality capture and a possible duplicate
log_type: "warning" and the report resolves to In Review.
Security note
Liveness videos and selfies are biometric data — the signed URLs are temporary and expire (after 4 hours by default). Treat them as short-lived: do not cache or surface them publicly. Typically your application only needsstatus, score, and the warnings — store as little as possible to minimize biometric data on your servers.
Related
- Liveness warnings — full warning enum, causes, and remediation.
- Webhooks — listen for
session.status.updatedto receive the report. - Data models — Liveness check — canonical schema with every field.
- Face match report — the companion 1:1 face match against the document portrait.