📄 document_info – Detailed Field Reference

The document_info object is part of the kyc_info.document section and contains metadata about the scanned document, the method of extraction, and the base64 images.

🧾 document_info Fields

🖼️ document_images Subfields

📑 API Documentation: document_status

The document_status object is part of the KYC API request under kyc_info.document. It contains detailed status information about the scanned identity document and the results of various checks performed during document validation.

🔗 Location in Payload

kyc_info.document.document_status

📘 Field Descriptions

🧾 Possible Values: nfc_scan_status

• NFC SCAN UNSUPPORTED BY CONFIG
• NFC SCAN NOT APPLICABLE
• NFC SCAN UNSUPPORTED BY DEVICE
• NFC SCAN PERFORMED
• NFC SCAN ERROR
• NFC SCAN BYPASSED
• NFC SCAN TIMED OUT

🧾 Possible Values : nfc_scan_status_reason

The nfc_scan_status_reason field appears under document_status and provides a descriptive explanation for the outcome of the NFC scan.

Below are the values defined in the REL-ID KYC API documentation:

These reasons are vital for troubleshooting document scan failures on mobile devices and determining whether fallback mechanisms (like barcode or visual extraction) were used.

🧾Possible Values : overall_document_status

The overall_document_status field appears under document_status and provides the final result after all validation checks on the scanned document have been performed.

This field helps backend systems understand whether the document passed validation, had issues, or was not checked.

overall_document_status should be used by the enterprise to determine whether to accept, flag, or reject the identity document.

🧠 How is overall_document_statuscalculated?

The value of overall_document_status is derived from the individual results of the following checks:

• NFC Scan
• Mandatory Check
• Unexpired Document Check
• Date of Birth Check
• Date of Issue Check
• Data Compliance Check
• Data Consistency Check
• Barcode Check
• Hologram Check
• Image Pattern Check

Each of these validations contributes to the final status, with critical failures typically resulting in ERROR and minor issues in WARNING.

🔍 API Documentation: checks_performed

The checks_performed array appears under kyc_info.document.document_status and lists the validation and authenticity checks performed on the scanned identity document.

Each check evaluates a specific aspect of the document and includes sub-details explaining the result and reasoning.

🔗 Location in Payload

kyc_info.document.document_status.checks_performed

📘 Description

Each element in the checks_performed array is a structured object with the following fields:

🧾 Example

{
  "check_category": "Data Validation",
  "check_name": "Mandatory Data",
  "check_status": 1,
  "check_detail": [
    {
      "element": "Date of birth",
      "status": "OK",
      "detail": "Field is present and valid",
      "actual_image": "<Base64>",
      "etalon_image": "<Base64>",
      "match_percentage": 95.0,
      "lcidName": "Latin",
      "source": "MRZ",
      "source1": "MRZ",
      "source2": "Visual"
    }
  ]
}

🧪 check_detail Fields

Each item in check_detail explains a field or image-level outcome.

actual_image and etalon_image : attribute will be extracted when the check category is "Document Authenticity” and the check name is "Image Pattern” or "Hologram"

🏷️ check_name Descriptions

🔹 Data Validation

🔹 Document Authenticity

The checks_performed section provides detailed insight into the integrity and authenticity of the submitted identity document.

🧾 API Documentation: identity_data

The identity_data field appears under kyc_info.document in the REL-ID KYC API request payload. It provides a simplified key-value representation of the user's identity attributes extracted from the scanned document.

🔗 Location in Payload

kyc_info.document.identity_data

📘 Description

identity_data offers a flat JSON structure that maps each extracted identity field (like name, date of birth, etc.) to its value. It is useful for quick integrations, form pre-fill, or UI display without needing to parse complex structures.

🧾 Example

{
  "Document number": "PA1234567",
  "Given name": "John",
  "Surname": "Doe",
  "Date of birth": "1990-01-01",
  "Date of issue": "2020-01-01",
  "Date of expiry": "2030-01-01",
  "Nationality": "IND"
}

📑 Notes

• Field names are locale-dependent and document-specific (they may differ across document types or languages).
• Values are strings and directly reflect what was extracted from the document.
• If a field was not extractable or missing, it may not appear in the object.
• This structure is a simplified output; for detailed source and validation info, refer to identity_data_details.

✅ Use Cases

• Quickly populate identity forms or onboarding screens
• Provide fallback if identity_data_details is too complex or missing
• Support frontend UI flows with minimal transformation

For deeper insights (source confidence, extraction method, validation status), use the corresponding identity_data_details section.

🗂️ API Documentation: identity_data_details

The identity_data_details field is part of the kyc_info.document object in the REL-ID KYC API request. It provides a structured, locale-based breakdown of each extracted identity field, including validation status and extraction source metadata.

🔗 Location in Payload

kyc_info.document.identity_data_details

📘 Description

Unlike identity_data, which provides a flat list of values, identity_data_details offers an in-depth structure that shows the value, status, and source-wise breakdown of each extracted field.

🧾 Example Structure

{
  "0": [
    {
      "field_name": "Surname",
      "field_details": {
        "field_value": "Doe",
        "field_status": "OK",
        "field_source_and_values": {
          "M": "Doe",
          "V": "Doe"
        }
      }
    }
  ]
}

🧬 Field Descriptions

➤ Locale Code ("0", "1062", etc.)

Each top-level key maps to a locale/language. Use document_info.field_locales to resolve these.

➤ Field Object

➤ field_details Subfields

✅ Use Cases

• Show exact field values from each scan source
• Run source-based trust scoring logic
• Debug field inconsistencies or OCR mismatches
• Multi-language/localization-aware field processing

Use identity_data_details when your application needs high-confidence, explainable field-level data integrity.