Skip to main content

Document Verification API - Detailed Documentation

The Document Verification API enables the submission and verification of identification documents through a multi-step journey or a single-step process. It also includes optional checks for age verification and disability assessment.

API Playground:

You can try the openJourney endpoint here.

Endpoints Overview

  1. Document Verification with Journey Build-Up:
    • Open a verification journey.
    • Upload document images (front, back, selfie).
    • Initiate document verification.
  2. Single-Step Verification:
    • Upload all images in a single request.
    • Get instant verification results.
  3. Age and Disability Check:
    • Verify user eligibility based on age or disability percentage.
  4. Error Handling & Codes:
    • Standardized error messages for seamless integration.

Authentication

To access the Address Verification API, authentication is required. A Bearer Token must be included in every request.
  • Tokens are valid for 60 minutes and must be refreshed after expiration.
  • Refer to the Authentication for detailed steps on obtaining a token.
  • Include the token in the Authorization header as follows:
Authorization: Bearer YOUR_ACCESS_TOKEN

API Base URL

Production:

Sandbox:


1. Document Verification with Journey Build-Up (Upcoming)

Description

This section covers the multi-step approach, where you first open a journey, then upload documents in steps, and finally call the verification endpoint(s).

1.1 Open Journey

Endpoint

POST /openJourney

Description

Starts a new verification journey where the customer can submit documents in steps.

Required Headers

Request Body Parameters

None required (optional metadata can be included).

Response Structure

Example Response

1.2 Add Image (Upcoming)

Endpoint

POST /addImage

Description

After opening a journey, you can upload an image representing the front/back of an ID or a selfie. Adds an image (front, back, or selfie) to the ongoing journey. Images can be submitted as base64-encoded strings or as file uploads.

Request Body Parameters

Example Request

Example Request with Multiple Images

1.3 Verify (Upcoming)

Endpoint

POST /verify

Description

Once you’ve uploaded all relevant images, you can call this endpoint to verify them. Initiates the verification of all images submitted in this journey. Returns a detailed verification result (see response structure below).

Required Headers

Request Body Parameters

Response Structure

Example Request

Example Response

1.4 Verify with Age and Disability Check (Upcoming)

Endpoint

POST /verify/age

Description

Performs an optional age/disability verification after documents are submitted. Checks if the user meets certain age or disability thresholds. Note: ageFrom and ageTo are mutually exclusive—do not use both in the same request.

Required Headers

Request Body Parameters

Response Structure

Example Request

Example Response

2. Single-Step Verification

Description

This section describes the single-step approach, bypassing the journey creation. You must provide all images in one request.

2.1 Verify in One Step

Endpoint

POST /verifySingle

Description

Bypasses the journey build-up and processes all images in one request. No feedback is provided if pages are missing—all must be submitted at once.

Required Headers

Request Body Parameters

Response Structure

Example Request

Error Handling & Codes

Below is how the Document Verification API handles errors. This section is divided into:
  1. General HTTP Status Codes - which apply across all endpoints.
  2. Generic Error Response Structure - the standard JSON format returned in error cases.
  3. Endpoint-Specific Error Scenarios - a reference table detailing common error codes for each endpoint.

General HTTP Status Codes

Generic Error Response Structure

When an error occurs (i.e., a 4xx or 5xx status code), the API returns a JSON body with the following format:

Response Structure

Example Response

  • errorCode is particularly useful for programmatic checks in client applications.
  • errorMessage should help developers quickly understand what went wrong.
  • details can be omitted if no extra info is needed.

Endpoint-Specific Error Scenarios

Each endpoint may have unique validation or domain-specific constraints. The table below summarizes common error codes per endpoint. All error responses conform to the Generic Error Response Structure above.

Handling Errors

  1. Check the HTTP status code returned from the API.
  2. Parse the JSON if the status code indicates an error (4xx or 5xx).
  3. Use errorCode to determine the type of error (e.g., JOURNEY_NOT_FOUND), and handle it in your client application (e.g., show a specific user message).
  4. Look at errorMessage for a human-readable explanation of the issue.
  5. Examine details if present, to get more granular context (e.g., which field triggered the error).