Overview
Warnings on the ID verification report flag every condition Didit observed while reading and validating the document. They land in thewarnings[] array on each item of id_verifications[] (see ID verification report), with the shape described in Data models — Warning object: feature, risk, additional_data, log_type, short_description, long_description, node_id.
Every warning has three layers:
- The
riskcode — a stable identifier you can match on in your code. - The
log_type— derived from the action your configuration assigns to the risk at evaluation time: Decline →error, Review →warning, anything else →information. - The decision impact — set by the workflow’s configurable risk groups. The same
riskcode can be routed to Approve, Review, or Decline depending on how your application is configured.
Auto-decline conditions
In workflows, the following risks always force the ID report (and the session) toDeclined. They cannot be configured:
For the standalone OCR API, the unconditional-decline set is
DOCUMENT_EXPIRED, MINIMUM_AGE_NOT_MET, PORTRAIT_IMAGE_NOT_DETECTED, SCREEN_CAPTURE_DETECTED, PRINTED_COPY_DETECTED, and PORTRAIT_MANIPULATION_DETECTED. In workflows, minimum age is configurable (default Decline) and the three document-liveness risks are threshold-driven (see below).
Configurable verification settings
In the Didit console, the remaining ID risks are grouped into settings you can route to Approve, Review, or Decline (per workflow, and per node in graph workflows):
Two ID risk families are threshold-driven instead of Approve/Review/Decline toggles:
- Document liveness —
SCREEN_CAPTURE_DETECTED,PRINTED_COPY_DETECTED,PORTRAIT_MANIPULATION_DETECTED. Each fraud type has its own decline and review thresholds: score below the decline threshold →error+ Declined; below the review threshold →warning+ In Review; otherwiseinformation. - Cross-camera face match —
LOW_FRONT_CAMERA_FACE_MATCH_SIMILARITY, governed bydocument_selfie_portrait_match_decline_threshold/document_selfie_portrait_match_review_threshold.
Warnings produced
Verified againstcollect_ocr_logs, the document-capture flow, and process_ocr_logs_and_get_status. Short descriptions below are the exact short_description strings returned by the API.
Document recognition and quality
The capture flow can also reject an upload with the feedback codes
IMAGE_RESOLUTION_TOO_LOW, DOCUMENT_NOT_FULLY_VISIBLE, and IMAGE_QUALITY_TOO_LOW. These prompt a retake in the SDK but are not persisted to the report’s warnings[] — only the blurry/dark/bright risks are.Field extraction
MRZ, QR, barcode
All three MRZ risks are skipped for document types with known-unreliable MRZs.Identity matching
Document liveness (tampering)
Threshold-driven per fraud type in workflows; unconditionally declining on the standalone OCR API.Expected-details mismatches
When you passexpected_details to a session, Didit raises a mismatch warning per field that does not match. One grouping (expected_details_mismatch_action, default Review) controls routing for all of these:
Each mismatch warning carries the expected and extracted values in
additional_data.
Age
Address
Cross-session document matches
In addition to the warnings above, the V3 ID report ships amatches[] array — up to 5 other documents in your application with the same date of birth, the same issuing country, and a highly similar full name (blocklisted documents additionally require an exact document-number match), excluding sessions that belong to the same user. Documents added to your blocklist appear with is_blocklisted: true. Documents on your allowlist still appear in matches, but their duplicate-user action is skipped.
Each match includes session_id, session_number, vendor_data, verification_date, user_details (name, document_type, document_number), status, is_blocklisted, api_service, and a signed front_image_url.
Examples
Configurable warning at its default routing (information)
Auto-decline on expired document
Expected-details mismatch with payload
Warning types
Each risk is assigned a severity based on your application’s configuration. The three severities are:Related
- ID verification report — full report schema and statuses.
- Document monitoring — how Didit detects tampering and cross-session duplicates.
- Webhooks —
session.status.updatedcarries the warnings as soon as the ID step finishes. - Data models — ID verification — canonical field-by-field schema.
- Data models — Warning object — the shape of every entry in
warnings[].