Skip to main content
POST
ID Verification (Document Front/Back)

Overview

ID Verification is a Gu1 verification service that validates an identity document by sending the front image (required) and optionally the back image (for two-sided documents such as national IDs). The API returns Approved or Declined, plus extracted data (name, document number, date of birth, address, MRZ, etc.) and optional warnings. No hosted session is involvedβ€”you send the images and get the result in one call.
When to use which
  • Session-based KYC (POST /api/kyc/validations): Full flow with hosted URL, live selfie, liveness, and document capture. Best for onboarding and regulated flows.
  • Face Match (POST /api/kyc/face-match): Compare two images (document portrait + selfie) to verify they are the same person; returns match + score.
  • ID Verification (POST /api/kyc/id-verification): Send document front (and optional back); get document validation, extracted data (MRZ, name, address, etc.), and Approved/Declined. Best when you already have document images and need extraction + validation only.

Prerequisites

Before using ID Verification:
  1. ID Verification integration enabled: Your organization must have the ID Verification KYC integration activated (e.g. in Marketplace / Integrations).
  2. Credentials configured: The API key for the ID Verification integration must be set in your organization’s KYC settings (configured by the Gu1 administrator). Only the API key is required (no webhook secret for this endpoint).
ID Verification is a Gu1 service. All verification is performed by Gu1 infrastructure.

Request

Endpoint

Content-Type

Only multipart/form-data is accepted. You can send images in either of two ways (or mix):
  1. As file parts: attach image/files to the form fields documentFront and (optional) documentBack.
  2. As base64 strings: send the same field names with base64-encoded image strings (with or without data:image/...;base64, prefix).
documentFront is required: you must send either a file or a base64 string for it. If neither is provided, the API returns 400. documentBack is optional. For each image, if you send both a file and a base64 string, the file is used.

Headers

Do not set Content-Type manually when using FormData; the client will set it with the correct boundary. If your account uses organization scoping, include:

Form Fields

documentFront
file | string
required
Front image of the identity document. Send as a file part (recommended) or as a string (base64, with or without data:image/...;base64, prefix). Formats: JPEG, PNG, WebP, TIFF, PDF. Max 5MB.
documentBack
file | string
Back image of the document (optional; required for two-sided documents such as national IDs). Same as documentFront: file part or base64 string.
entityId
string
Optional UUID of the person entity to associate with this check. Used for audit and for listing verifications by entity.
vendorData
string
Optional reference (e.g. your user ID) for tracking. Stored with the audit record.
doubleCheckRenaper
boolean
When true, after document verification is approved, runs RENAPER data check (DNI + gender + trΓ‘mite from OCR vs renaper/data). Requires org RENAPER credentials. Query overrides body.
doubleCheckRenaper
boolean
Same as query param doubleCheckRenaper.
performDocumentLiveness
boolean
Whether to perform document liveness (detect screen/copy). Default false. Send as string "true" or "false" in form.
minimumAge
number
Minimum age (1–120); users below are Declined. Optional. Send as string in form.
expirationDateNotDetectedAction
string
"NO_ACTION" or "DECLINE" when expiration date is not detected. Optional.
invalidMrzAction
string
"NO_ACTION" or "DECLINE" when MRZ is invalid or unreadable. Optional.
inconsistentDataAction
string
"NO_ACTION" or "DECLINE" when visual zone data does not match MRZ. Optional.

Response

Success Response (200 OK)

If RENAPER double-check fails after OCR approval, status becomes "declined" and RENAPER codes are added to warnings.

extractedData fields

The following fields are returned in extractedData and stored on id_verification_verifications.extracted_data (list/get audit endpoints). Empty fields are omitted. Identity and document (common): Supplementary (nested; may be empty):
Promoted fields vs. extension bucket
  • Common keys (taxNumber, firstSurname, secondSurname, firstIssueDate, ejemplar, etc.) are promoted to the top level of extractedData when OCR returns them.
  • Any other document keys stay in extractedData.extraFields (same object on POST and audit list/get).
Not included in API responses or audit JSON
  • Temporary external image URLs from the verification pipeline β€” use stored document images (document-front-image / document-back-image) for images Gu1 saved from your upload.
  • Full raw verification response body (not exposed in production APIs).
Example (approved):
Example (declined with warnings and LATAM extra fields):
Example (Argentine DNI):

Example Request

Error Responses

Common error codes:

Audit and Listing Verifications

Every ID Verification request (success or failure) is stored in id_verification_verifications for audit and compliance. The response includes verificationId (the audit record ID) when persistence succeeds. All endpoints below are part of the Gu1 API.

Get a Single Verification

Returns one audit record by ID. Path: id β€” UUID of the verification (from the POST response verificationId or from the list). Response (200): Same shape as one item in the list: id, organizationId, entityId, status, requestId, vendorData, errorMessage, warnings, extractedData, createdAt, documentFrontStoragePath, documentBackStoragePath, storageProvider, etc.
404 if not found or not in your organization.

List Audit Records

Query parameters: Response: { "verifications": [ ... ], "pagination": { "limit", "offset", "total" } }. Each verification includes id, entityId, status, requestId, extractedData, warnings, errorMessage, createdAt, and storage paths when images were stored.

Get Stored Document Images

If the verification has stored images (documentFrontStoragePath / documentBackStoragePath), you can stream them with:
Path: id β€” UUID of the verification. Response: Image bytes (e.g. Content-Type: image/jpeg). 404 if the verification does not exist or that side was not stored.

Coexistence with Other KYC Flows

  • Session flow creates a kyc_validations record and uses a hosted URL; the stored decision can include document, liveness, and face match from the live session.
  • Face Match compares document portrait + selfie and returns match + score; audit in face_match_verifications.
  • ID Verification validates the document (front/back), extracts data, and returns Approved/Declined; audit in id_verification_verifications. It does not create a kyc_validations record. Use it when you need document-only validation and extraction without a hosted session.

Next Steps

Face Match (Document + Selfie)

Compare document photo and selfie

Create KYC Validation

Session-based verification with hosted URL