Face Match (Document + Selfie)
Face Match
Face Match (Document + Selfie)
Verify that a selfie and a document photo belong to the same person via a single API call — in the gu1 KYC API for identity verification flows.
POST
Face Match (Document + Selfie)
Overview
Face Match is a Gu1 verification service that compares two images: a selfie (current photo of the person) and a document reference image (e.g. the portrait from an ID). The API returns whether the faces match (same person) and a similarity score. No hosted session or real-time liveness 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): You send two images (as files or base64); you get back match + score. Best for validating document + selfie you already have (e.g. from your own app).
Prerequisites
Before using Face Match:- Face Match integration enabled: Your organization must have the Face Match KYC integration activated (e.g. in Marketplace / Integrations).
- Credentials configured: API key and webhook secret for the Face Match integration must be set in your organization’s KYC settings (configured by the Gu1 administrator).
- Threshold (optional): The minimum score required to approve (0–100) is configured in Organization Settings → KYC (Face Match card). If not set, the default is 30. Only your organization’s admins can change this value.
Face Match is a Gu1 service. All verification is performed by Gu1 infrastructure.
Request
Endpoint
Content-Type
Onlymultipart/form-data is accepted. You can send images in either of two ways (or mix):
- As file parts: attach image files to the form fields
documentImageandselfieImage. - As base64 strings: send the same field names with base64-encoded image strings (with or without
data:image/...;base64,prefix).
Headers
Content-Type manually when using FormData; the client will set it with the correct boundary.
If your account uses organization scoping, include:
Form Fields
file | string
required
Reference image (e.g. portrait from ID document). Send as a file part (recommended) or as a string (base64, with or without
data:image/...;base64, prefix). Formats: JPEG, PNG, WebP, TIFF. Max 5MB.file | string
required
Selfie image. Same as
documentImage: file part or base64 string. Required.string
Optional UUID of the person entity to associate with this check. Used for audit and for listing verifications by entity.
number
Optional. Score threshold 0–100; results below are declined. If omitted, the organization’s configured threshold (or default 30) is used.
string
Optional reference (e.g. your user ID) for tracking. Stored with the audit record.
boolean
When
true, after Gu1 face match approves, runs RENAPER biometric (validate-dni with the selfie) and data (renaper/data: DNI + trámite) checks. Requires org RENAPER credentials and active Marketplace integrations: ar_renaper_data_enrichment and ar_renaper_validate_dni_enrichment. Query overrides body if both are sent.boolean
Same as query param
doubleCheckRenaper.string
DNI for RENAPER when
doubleCheckRenaper=true. Optional if entityId resolves taxId or person.idNumber.string
Gender for RENAPER (
M, F, male, female). Required for double-check unless resolved from linked entity.string
required
Número de trámite for RENAPER data check. Required when
doubleCheckRenaper=true.Response
Success Response (200 OK)
If RENAPER double-check fails after provider approval,
match becomes false, status becomes "declined", and RENAPER codes (e.g. RENAPER_BIOMETRIC_NOT_MATCH) are added to warnings. Allow 60+ seconds HTTP timeout when using double-check (biometric polling).
Example:
Example Request
Error Responses
Common error codes:Audit and Listing Verifications
Every Face Match request (success or failure) is stored inface_match_verifications for audit and compliance. The response includes verificationId (the audit record ID). Each stored record also saves the threshold that was used at the time of the call (so you can show it in history even if the org threshold changes later).
List Audit Records
Response:
{ "verifications": [ ... ], "scoreDeclineThreshold": 30, "pagination": { "limit", "offset", "total" } }. Each verification includes id, entityId, status, match, score, threshold (the value used for that run), createdAt, and optional image paths for audit.
Get Verification by ID
Retrieve a single Face Match audit record by itsverificationId (returned in the POST response or in the list).
id — UUID of the verification (same as verificationId from the POST or list).
Response (200): One verification object with the same fields as each item in the list: id, organizationId, entityId, status, match, score, requestId, vendorData, errorMessage, triggeredByUserId, createdAt, documentStoragePath, selfieStoragePath, storageProvider, threshold.
Errors: 404 NOT_FOUND if the ID does not exist or belongs to another organization; 401 UNAUTHORIZED if not authenticated.
Coexistence with Session-Based KYC
- Session flow creates a
kyc_validationsrecord, sends the user to a hosted URL, and updates status via webhooks. The stored decision includes document, liveness, and face match from the live session. - Face Match creates an audit record in
face_match_verificationsand returns the result in the same request. It does not create akyc_validationsrecord. Use it when you need a one-off check (e.g. “are these two images the same person?”) without a hosted session. - Both use the same organization KYC configuration. The threshold for Face Match is set in Organization Settings → KYC (Face Match card).
Next Steps
Create KYC Validation
Session-based verification with hosted URL
List Validations
List KYC validations by entity