Skip to main content

Overview

Warnings on the ID verification report flag every condition Didit observed while reading and validating the document. They land in the warnings[] 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:
  1. The risk code — a stable identifier you can match on in your code.
  2. The log_type — derived from the action your configuration assigns to the risk at evaluation time: Decline → error, Review → warning, anything else → information.
  3. The decision impact — set by the workflow’s configurable risk groups. The same risk code 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) to Declined. 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 livenessSCREEN_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; otherwise information.
  • Cross-camera face matchLOW_FRONT_CAMERA_FACE_MATCH_SIMILARITY, governed by document_selfie_portrait_match_decline_threshold / document_selfie_portrait_match_review_threshold.

Warnings produced

Verified against collect_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 pass expected_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 a matches[] 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: