Create KYC Validation
Session-based validation
Create KYC Validation
Initiate a KYC verification session for a person entity — in the gu1 KYC API for identity verification flows, with examples for create validation use cases.
POST
Create KYC Validation
Overview
This endpoint creates a new KYC validation session for a person entity using a configured integration provider. After creating the validation, you’ll receive a verification URL that you can share with your customer to complete identity verification.Complete Flow Diagram
Full sequence from entity creation to KYC validation (production flow; in sandbox with test document numbers the provider step is skipped and the API returns the mock result and webhooks immediately—see Sandbox mock data):Key Points in the Flow
Key Points in the Flow
1. Entity and duplicate taxId
- Create the person entity first via
POST /api/entities(withcountryCode). If thetaxIdalready exists in the organization, the API returns 409 and does not create a duplicate; use the existing entity’s ID. - You need an existing
entityIdto create a KYC validation.
global_gueno_validation_kycis the standard code for full KYC verification and works in sandbox with no extra setup.
- In production, the response includes
providerSessionUrl. Send that URL to your user; they complete the flow on the provider’s hosted page (document + selfie). The URL is valid untilexpiresAt. - In sandbox, if the entity’s document number is in the test list, no provider session is used: the API returns 201 with
pendingstatus and moments later updates the validation and sends webhooks (e.g.kyc.validation_approvedorkyc.validation_rejected) with no user step. Important: You must have a webhook endpoint configured to receive the responses - see Sandbox mock data.
- When the validation finishes, the API sends a webhook to your URL. The event is one of:
kyc.validation_approved,kyc.validation_rejected,kyc.validation_abandoned,kyc.validation_expired,kyc.validation_cancelled(not a single “completed” event). The payload is the full validation object. - You can also poll
GET /api/kyc/validations/:idfor status updates.
Prerequisites
Before creating a KYC validation:- Person entity must exist: Create a person entity using the Entities API
- KYC integration configured: Your organization must have a KYC integration provider activated (e.g.,
global_gueno_validation_kyc) - Valid API key: Authenticate with your API key
Sandbox vs Production: Sandbox environments do NOT require profile setup or pre-configuration. You can test KYC validations immediately in sandbox with test data. Production environments require:
- Completed organization onboarding
- KYC integration provider activated by gu1 team
- Sufficient credit balance for KYC operations
Mock Data (Sandbox)
In sandbox, when the person entity’s document number (taxId) matches one of our test values, the API returns an immediate mock result (e.g. approved, rejected, cancelled) and sends the corresponding webhooks—no real verification is run. Document format does not matter (e.g. 99.990.001 and 99990001 both work).
For the full list of test document numbers by format (Argentina DNI/CUIT, Brazil CPF/CNPJ), expected outcomes, and example responses, see Sandbox mock data.
Important Behaviors
Duplicate taxId (POST /entities)
Multiple KYC Validations per Entity
You can create multiple KYC validations for the same entity:- Each validation gets a unique ID and session
- Only the most recent approved validation is marked as
isCurrent: true - Use cases: Re-verification, expired validations, failed attempts
- If the entity already has an open validation (
pending,in_progress, orin_review), create returns409 VALIDATION_IN_PROGRESSwithactiveValidationId— cancel that validation first, then create again
Additive contract: Existing clients that only read
error and message are unchanged. activeValidationId is optional metadata on the 409 response to skip an extra lookup before cancel.Request
Endpoint
Headers
Query Parameters (Optional)
boolean
When
true, enables RENAPER double-check for Argentina entities. On terminal statuses the API queries the official registry (data and, when applicable, biometrics) and stores results in metadata. Only when OCR KYC verification returns status approved can a cross-check failure automatically set the validation to rejected; on in_review or rejected the check is informational (enforcementApplied: false).Type: boolean (e.g. ?doubleCheckRenaper=true)Requirements: Entity must be from Argentina (countryCode === 'AR'), and the organization must have RENAPER credentials configured in System Settings → Organizations → Config. If credentials are missing, the creation may fail or the double-check will be skipped depending on configuration.Body Parameters
Provide exactly one entity identifier:string
The UUID of the person entity to verifyType:
string (uuid)string
Your external ID for the entity (
entities.externalId in Gu1).string
Tax or document number. Gu1 resolves it with normalized match on
entities.tax_id. The entity must exist (404 if not found).In sandbox,
GET /api/entities/by-tax-id/{taxId} can return a synthetic preview for catalog test numbers (sandboxMock: true) without a DB row. POST /validations still requires a real persisted entity.string
required
The integration provider code for KYC validationStandard Value:
global_gueno_validation_kyc (recommended for most use cases)Type: string (min length: 1)What is integrationCode?The
integrationCode identifies which KYC provider integration to use for verification. Think of it as selecting the verification service.Available Integration Codes:global_gueno_validation_kyc- Recommended - Full KYC with document + selfie + face match + liveness- Custom codes may be configured for your organization (contact support)
- Log in to gu1 Dashboard
- Navigate to Settings → Integrations → KYC Providers
- Your active integration code will be listed there
global_gueno_validation_kyc works immediately with no configuration.boolean
Same as query param
doubleCheckRenaper. When true, enables RENAPER double-check for Argentina. Can be sent in the body or as ?doubleCheckRenaper=true. If both are present, the query param takes precedence.string[]
Optional list of KYC warning risk codes (exact strings). Stored on the validation as
metadata.omitWarnings. After the session completes, if the validation would be in_review, warnings is non-empty, and every code in warnings appears in this list, the API sets status to approved and keeps all warnings for display and audit. If any warning is not in omitWarnings, status stays in_review. If warnings is empty while status is in_review, this rule does not auto-approve. Invalid or unknown codes in the request body return 400. When the rule applies, metadata.kycOmitWarningsApplied records the decision timestamp and matched warnings.Non-omittable codes (e.g. GUENO_CROSS_ENTITY_DUPLICATED) are rejected in this field with 400 and always block omit auto-approve even if present in warnings.Type: string[] (each element must be an allowlisted code; duplicates are ignored)Response
Success Response (201 Created)
metadata.doubleChecks.renaper is set to true at creation. After OCR KYC verification completes and the double-check runs, metadata.responseDoubleChecks.renaper is populated (see RENAPER double-check below).
Response Fields
string
Unique identifier for this KYC validation
string
The person entity being verified
string
Your organization ID
string
Identity verification session identifier
string
Current validation status. Possible values:
pending- Validation created, waiting for customer to startin_progress- Customer is completing verification (filling out form)in_review- Verification completed, requires manual review from compliance teamapproved- Verification successfulrejected- Verification failedexpired- Verification session expired (e.g. after 7 days)abandoned- Customer started but didn’t completecancelled- Validation manually cancelled
string
KYC provider name
string
The verification URL to share with your customer
boolean
Whether this is the current active validation for the entity
object
Custom metadata. When RENAPER double-check is requested, includes
doubleChecks: { renaper: true }. After approval and double-check execution, may include responseDoubleChecks.renaper (see RENAPER double-check section).string
Timestamp when validation was created
string
Timestamp of last update
After approval, media keys appear inside
decision. To download files (images, video), use GET /api/kyc/validations/:id/media?key=... with Authorization: Bearer. Full details: Get KYC validation media.Example Request
Error Responses
Entity Not Found (404)
Invalid Entity Type (400)
KYC Not Configured (400)
Validation In Progress (409)
When the entity already has an open validation (pending, in_progress, or in_review), Gu1 syncs with the hosted capture session when possible, then rejects a second create:
409 → DELETE /api/kyc/validations/{activeValidationId}/cancel → one new POST /api/kyc/validations.
Terminal validations (approved, rejected, cancelled, expired, abandoned) do not block creating a new one.
RENAPER Double-Check (Argentina)
WhendoubleCheckRenaper is true and the entity is from Argentina, on each terminal status (approved, rejected, in_review) the API runs a cross-check against the official Argentine registry (RENAPER) when sufficient OCR data exists. Automatic rejection by RENAPER only applies when OCR KYC verification returned status approved.
How to Send It
- Body:
{ "entityId": "...", "integrationCode": "...", "doubleCheckRenaper": true } - Query:
POST /api/kyc/validations?doubleCheckRenaper=truewith the same body (without the field). Query param overrides body if both are present.
When It Runs
- Validation is created with
metadata.doubleChecks.renaper: true. - User completes verification; OCR KYC verification returns a terminal status.
- API calls RENAPER (data + biometrics when applicable) and stores
comparisonResultsin metadata. - If status is
approvedand the cross-check fails → validation becomesrejected. - If status is
in_revieworrejected→ results are informational; mismatch codes are added towarningswithout replacing OCR verification warnings. - Manual approve from
in_reviewdoes not re-run RENAPER; the human decision stands on the data already shown in review.
Where the Result Is Stored
All RENAPER double-check results are stored inmetadata.responseDoubleChecks.renaper. Mismatch codes are added to metadata.warnings alongside OCR KYC verification warnings. errorCode on the renaper object keeps the first failure for compatibility; UIs can list every code from comparisonResults and warnings.
Shape of metadata.responseDoubleChecks.renaper:
renaperData shape
This is the unmodified body returned by the registry via ms-providers (POST …/provider-records/renaper/data). Gu1 forwards it as-is in metadata.responseDoubleChecks.renaper.renaperData. Field names use snake_case; all fields are optional depending on what RENAPER returns for each lookup.
Example (successful double-check, matchResult: "match"):
In sandbox, the same mock values appear in KYC sandbox mock data.
comparisonResults shape
Per-field map (dni, tramite, name, ejemplar, dateOfBirth, expirationDate). Each entry may include:
For
ejemplar, the OCR value is extractedData.ejemplar (see extractedData fields). Comparison runs when both OCR and RENAPER values exist.
Example — extractedData on an approved KYC validation (Argentina):
renaperBiometric shape
Nested under metadata.responseDoubleChecks.renaper.renaperBiometric when the org has biometric credentials and the KYC session provides a selfie. Gu1 sends one selfie to validate-dni; RENAPER compares it to the ID photo on file.
Full responseDoubleChecks.renaper example
renaperBiometric and comparisonResults entries may be omitted depending on credentials, OCR data, or selfie availability.
Error Codes (When RENAPER Fails)
When the double-check fails,metadata.warnings contains one of the following codes (and metadata.responseDoubleChecks.renaper.errorCode is set to the same value). Your UI should translate these codes into user-facing messages.
When RENAPER enforcement applies (automatic rejection)
Why the validation may be rejected
RENAPER can change status torejected only on the direct approved path. On in_review / rejected / manual approve, failures appear as codes in metadata.warnings and in metadata.responseDoubleChecks.renaper without auto-rejection. Use the table above and translation keys (e.g. kyc.rejectionReasonCodes.*).
Next Steps
After creating a validation:- Extract the verification URL from
providerSessionUrl - Share the URL with your customer via email, SMS, or in-app
- Set up webhook endpoint to receive completion notifications
- Monitor validation status using the validation ID
- After approval, read media keys from
decisionand download files — see Get KYC validation media
Get KYC URL
Learn how to retrieve the URL
Webhook Integration
Configure webhook notifications