> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs.veriff.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Create session
> ### Creates a verification session with the data specified in the request body
#### When to use this endpoint
- Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.
#### Request body content
The contents of the request body depends on:
- Whether you are using the SDK or API to capture end-user data
- The type of verification solution the session is created for
Minimum request body:
- Empty `verification` object
Payload examples:
- Click on the **"Show examples" button** in "Request" section to see **request body examples for specific solutions/products**.
#### Response data
Once you create the verification session, you receive:
- Unique session `id` (store this - required for other endpoints)
- Unique `sessionToken` (legacy purposes, see [FAQ](https://devdocs.veriff.com/docs/general-faq#what-is-a-sessiontoken))
- Session URL in `verification.url` parameter (required for [SDK integrations](https://devdocs.veriff.com/docs/sdk-guide))
#### Getting session results
After the end-user completes the verification:
- **Primary:** [webhook](https://devdocs.veriff.com/docs/webhooks-guide) notifications sent to `webhook URL`
- **Secondary:** Poll [`GET /v1/sessions/{id}/decision`](https://devdocs.veriff.com/apidocs/v1sessionsiddecision-1) endpoint
- **Backup:** Use polling if webhook delivery fails
#### Implementation notes
- Store the returned session `id` - it is required for all other session-related endpoints
- Always ensure that you use the correct API URL to send requests. See the [API URL section](https://devdocs.veriff.com/apidocs/veriff-public-api-guides#api-url) for more info.
- See [Javascript sample implementation](https://github.com/Veriff/js-integration-demo) for SDK integration examples
- The order of parameters in the real API response can differ from the order you see in this documentation.
This is expected and part of the [Backwards compatible changes](https://devdocs.veriff.com/apidocs/veriff-public-api-guides#backwards-compatible-changes) requirements.
#### Additional info: end-user flow after session creation
1. Create session → Get `session.verification.url`
2. Redirect end-user to `verification.url`
3. End-user completes verification flow
4. End-user redirected to your callback URL (if configured)
5. Receive webhook notification OR poll for results
## OpenAPI
````json POST /v1/sessions
{
"openapi": "3.0.0",
"info": {
"title": "Veriff Public API",
"version": "1.0.0"
},
"servers": [
{
"url": "https://example-base-url"
}
],
"tags": [
{
"name": "Session management",
"description": "Create and manage verification sessions"
},
{
"name": "Data submission",
"description": "Upload media and submit verification data during the session"
},
{
"name": "Session results",
"description": "Retrieve verification decisions and results"
},
{
"name": "Media management",
"description": "Access and download verification media files and media file-related data"
},
{
"name": "Database verification",
"description": "Validate identity against national registries and databases"
},
{
"name": "Certificate management",
"description": "Retrieve long-term preservation certificates and their source documents for a verification session"
}
],
"paths": {
"/v1/sessions": {
"post": {
"summary": "Create session",
"description": "### Creates a verification session with the data specified in the request body\n\n#### When to use this endpoint\n\n- Use this endpoint to **initiate a new verification session** for an end-user. Every verification flow begins with creating a session.\n\n#### Request body content\n\nThe contents of the request body depends on:\n- Whether you are using the SDK or API to capture end-user data\n- The type of verification solution the session is created for\n\nMinimum request body:\n- Empty `verification` object\n\nPayload examples:\n- Click on the **\"Show examples\" button** in \"Request\" section to see **request body examples for specific solutions/products**.\n\n#### Response data\n\nOnce you create the verification session, you receive:\n- Unique session `id` (store this - required for other endpoints)\n- Unique `sessionToken` (legacy purposes, see [FAQ](https://devdocs.veriff.com/docs/general-faq#what-is-a-sessiontoken))\n- Session URL in `verification.url` parameter (required for [SDK integrations](https://devdocs.veriff.com/docs/sdk-guide))\n\n#### Getting session results\n\nAfter the end-user completes the verification:\n\n- **Primary:** [webhook](https://devdocs.veriff.com/docs/webhooks-guide) notifications sent to `webhook URL`\n- **Secondary:** Poll [`GET /v1/sessions/{id}/decision`](https://devdocs.veriff.com/apidocs/v1sessionsiddecision-1) endpoint \n- **Backup:** Use polling if webhook delivery fails\n\n#### Implementation notes\n\n- Store the returned session `id` - it is required for all other session-related endpoints\n- Always ensure that you use the correct API URL to send requests. See the [API URL section](https://devdocs.veriff.com/apidocs/veriff-public-api-guides#api-url) for more info.\n- See [Javascript sample implementation](https://github.com/Veriff/js-integration-demo) for SDK integration examples\n- The order of parameters in the real API response can differ from the order you see in this documentation. \n This is expected and part of the [Backwards compatible changes](https://devdocs.veriff.com/apidocs/veriff-public-api-guides#backwards-compatible-changes) requirements. \n\n#### Additional info: end-user flow after session creation\n\n1. Create session → Get `session.verification.url`\n2. Redirect end-user to `verification.url`\n3. End-user completes verification flow\n4. End-user redirected to your callback URL (if configured)\n5. Receive webhook notification OR poll for results\n",
"operationId": "createSession",
"tags": [
"Session management"
],
"parameters": [
{
"name": "X-AUTH-CLIENT",
"in": "header",
"description": "Your integration's API key (occasionally referred to as the \"Token\", \"API public key\" or \"Publishable key\"). Required for all API requests.\n\nYou can find your API key in the Veriff Customer Portal under Settings > API keys.\n",
"required": "true",
"schema": {
"type": "string"
}
},
{
"name": "Content-Type",
"in": "header",
"description": "Must be set to application/json",
"required": "true",
"schema": {
"type": "string",
"enum": [
"application/json"
]
},
"example": "application/json"
}
],
"requestBody": {
"required": "true",
"description": "Session initialization data",
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/CreateSessionRequestBody"
},
"examples": {
"minimal_payload": {
"description": "Empty verification object - minimum required to create a session",
"value": {
"verification": {}
}
},
"expanded_payload": {
"description": "Session with person data, document details, and end-user ID",
"value": {
"verification": {
"callback": "https://example.com/callback",
"person": {
"firstName": "John",
"lastName": "Smith",
"idNumber": "123456789"
},
"document": {
"number": "B01234567",
"type": "PASSPORT",
"country": "US"
},
"endUserId": "c1de400b-1877-4284-8494-071d37916197"
}
}
},
"expanded_payload_with_hostAppLink": {
"description": "Session with person data, document details, end-user ID, and host app link",
"value": {
"verification": {
"callback": "https://example.com/callback",
"hostAppLink": "myapp://verification/complete",
"person": {
"firstName": "John",
"lastName": "Smith",
"idNumber": "123456789"
},
"document": {
"number": "B01234567",
"type": "PASSPORT",
"country": "US"
},
"endUserId": "c1de400b-1877-4284-8494-071d37916197"
}
}
},
"session_with_service_coverage": {
"description": "Session with service coverage configuration",
"value": {
"verification": {
"serviceCoverage": {
"country": "US"
}
}
}
},
"session_with_consent": {
"description": "Session with person data, document details, end-user ID, and consent array",
"value": {
"verification": {
"person": {
"firstName": "John",
"lastName": "Smith",
"idNumber": "123456789"
},
"document": {
"number": "B01234567",
"type": "PASSPORT",
"country": "US"
},
"endUserId": "c1de400b-1877-4284-8494-071d37916197",
"consents": [
{
"type": "ine",
"approved": "true",
"text": "User agrees to share their INE details",
"timestamp": "2026-05-07T08:00:00Z"
}
]
}
}
},
"aml_screening_standalone": {
"description": "Session for [AML/sanctions screening](https://devdocs.veriff.com/docs/aml-screening-solution) with required person data",
"value": {
"verification": {
"person": {
"firstName": "John",
"lastName": "Smith",
"dateOfBirth": "1990-01-01"
}
}
}
},
"br_cadastro_unico_database": {
"description": "Session to validate Brazilian users against social benefit registries. See [here](https://devdocs.veriff.com/docs/brazilian-cadastro-unico-database-verification) for full documentation.",
"value": {
"verification": {
"person": {
"idNumber": "12345678901",
"dateOfBirth": "1990-01-15"
}
}
}
},
"br_probet_database": {
"description": "Session to validate users against Brazil's betting exclusion registries. See [here](https://devdocs.veriff.com/docs/pro-bet-database-verification) for full documentation.",
"value": {
"verification": {
"person": {
"idNumber": "12345678901",
"dateOfBirth": "1990-01-15"
}
}
}
},
"mx_curp_db_verification": {
"description": "Session for [Mexican CURP database verification](https://devdocs.veriff.com/docs/curp-database-verification) using person ID number",
"value": {
"verification": {
"person": {
"idNumber": "VISH560427MSRLNL06"
}
}
}
},
"mx_ine_db_verification_using_ife": {
"description": "Session for [Mexican INE database verification](https://devdocs.veriff.com/docs/ine-database-verification) using CIC and IFE identifier (OCR code) for card type D",
"value": {
"verification": {
"callback": "https://yourwebsite.com/webhook",
"document": {
"number": "123456789M00000000",
"documentNumberIdentifiers": {
"mxIfe": "1234567890123"
}
}
}
}
},
"mx_ine_db_verification_using_ine": {
"description": "Session for [Mexican INE database verification](https://devdocs.veriff.com/docs/ine-database-verification) using CIC and INE identifier (Identificador Ciudadano) for card types E, F, G, and H",
"value": {
"verification": {
"callback": "https://yourwebsite.com/webhook",
"document": {
"number": "123456789M00000000",
"documentNumberIdentifiers": {
"mxIne": "1234567890123"
}
}
}
}
},
"proof_of_address_address_matching": {
"description": "Proof of Address [address matching](https://devdocs.veriff.com/docs/proof-of-address-verification#address-matching) session to compare addresses from two different sources",
"value": {
"verification": {
"person": {
"firstName": "John",
"lastName": "Smith"
},
"address": {
"fullAddress": "123, Main Street, Your County, Anytown 12345"
},
"proofOfAddress": {
"acceptableTypes": [
{
"name": "UTILITY_BILL"
},
{
"name": "PHONE_BILL"
},
{
"name": "TAX_DOCUMENT"
}
]
},
"endUserId": "c1de400b-1877-4284-8494-071d37916197"
}
}
},
"proof_of_address_simple": {
"description": "Can be used for [address extraction](https://devdocs.veriff.com/docs/proof-of-address-verification#proof-of-address-extraction) and [address validation](https://devdocs.veriff.com/docs/proof-of-address-verification#address-validation) solutions. See the full Proof of Address documentation [here](https://devdocs.veriff.com/docs/proof-of-address-verification)",
"value": {
"verification": {
"proofOfAddress": {
"acceptableTypes": [
{
"name": "UTILITY_BILL"
},
{
"name": "PHONE_BILL"
},
{
"name": "TAX_DOCUMENT"
}
]
},
"endUserId": "c1de400b-1877-4284-8494-071d37916197"
}
}
},
"proof_of_address_with_name_match": {
"description": "Can be used for [address extraction](https://devdocs.veriff.com/docs/proof-of-address-verification#proof-of-address-extraction) and [address validation](https://devdocs.veriff.com/docs/proof-of-address-verification#address-validation) solutions. See the full Proof of Address documentation [here](https://devdocs.veriff.com/docs/proof-of-address-verification)",
"value": {
"verification": {
"person": {
"firstName": "John",
"lastName": "Smith"
},
"proofOfAddress": {
"acceptableTypes": [
{
"name": "UTILITY_BILL"
},
{
"name": "PHONE_BILL"
},
{
"name": "TAX_DOCUMENT"
}
]
},
"endUserId": "c1de400b-1877-4284-8494-071d37916197"
}
}
},
"selfie_to_selfie_biometric": {
"description": "Session for [Biometric Authentication](https://devdocs.veriff.com/docs/biometric-authentication) to verify identity by comparing two selfie images",
"value": {
"verification": {
"person": {
"firstName": "John",
"lastName": "Smith"
},
"endUserId": "a1b2c35d-e8f7-6d5e-3cd2-a1b2c35db3d4",
"vendorData": "12345678"
}
}
},
"session_with_tag_parameter": {
"description": "Session with custom tag parameter",
"value": {
"verification": {
"vendorData": "12345678",
"tag": "your_custom_tag_max_64_characters"
}
}
},
"uk_diatf_m1b": {
"description": "Session for UK DIATF M1B verification with full address",
"value": {
"verification": {
"address": {
"fullAddress": "123, Main Street, Your County, Anytown 12345"
}
}
}
},
"us_light_kyc": {
"description": "Session for US Database Verification: [Light KYC verification](https://devdocs.veriff.com/docs/us-database-verification#light-kyc) with person details and address",
"value": {
"verification": {
"person": {
"firstName": "John",
"lastName": "Smith",
"dateOfBirth": "1990-01-01",
"phoneNumber": "8888888888"
},
"address": {
"fullAddress": "123, Main Street, Your County, Anytown 12345"
}
}
}
},
"udocs_no_init_data": {
"description": "Session for [Unstructured Docs](https://devdocs.veriff.com/docs/unstructured-docs)\nverification without initData — for document extraction only\n(no InitData Matching validation).\n",
"value": {
"verification": {}
}
},
"udocs_with_init_data": {
"description": "Session for [Unstructured Docs](https://devdocs.veriff.com/docs/unstructured-docs)\nverification with all possible initData fields.\n",
"value": {
"verification": {
"document": {
"number": "847293651024738569"
},
"person": {
"fullName": "JUAN MARTINEZ",
"occupation": "Driver"
},
"address": {
"fullAddress": "AV INSURGENTES SUR 2847 PISO 3 COL DEL VALLE BENITO JUAREZ CIUDAD DE MEXICO MEXICO CP 03100"
},
"endUserId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
}
}
},
"us_ssn_validation": {
"description": "Session for US Database Verification: [SSN check](https://devdocs.veriff.com/docs/us-database-verification#ssn-check) with document number and person data",
"value": {
"verification": {
"person": {
"firstName": "John",
"lastName": "Smith",
"dateOfBirth": "1990-01-01"
},
"document": {
"number": "123456789"
}
}
}
}
}
}
}
},
"responses": {
"200": {
"description": "Created session",
"headers": {
"Content-Type": {
"description": "Response content type.",
"schema": {
"type": "string",
"example": "application/json"
}
},
"X-AUTH-CLIENT": {
"description": "API key echoed back in response.",
"schema": {
"type": "string"
}
},
"X-HMAC-SIGNATURE": {
"description": "Response body signed with the shared secret key. Required to authenticate the response sender.",
"schema": {
"type": "string"
}
}
},
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/SessionCreatedResponse"
}
}
}
},
"400": {
"description": "Bad request",
"headers": {
"Content-Type": {
"description": "Response content type.",
"schema": {
"type": "string",
"example": "application/json"
}
},
"X-AUTH-CLIENT": {
"description": "API key echoed back in response.",
"schema": {
"type": "string"
}
},
"X-HMAC-SIGNATURE": {
"description": "Response body signed with the shared secret key. Required to authenticate the response sender.",
"schema": {
"type": "string"
}
}
},
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/BadRequestErrorResponse"
}
}
}
},
"401": {
"description": "Unauthorized",
"headers": {
"Content-Type": {
"description": "Response content type.",
"schema": {
"type": "string",
"example": "application/json"
}
},
"X-AUTH-CLIENT": {
"description": "API key echoed back in response.",
"schema": {
"type": "string"
}
},
"X-HMAC-SIGNATURE": {
"description": "Response body signed with the shared secret key. Required to authenticate the response sender.",
"schema": {
"type": "string"
}
}
},
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/UnauthorizedErrorResponse"
}
}
}
},
"429": {
"description": "Too many requests",
"headers": {
"Content-Type": {
"description": "Response content type.",
"schema": {
"type": "string",
"example": "application/json"
}
},
"X-AUTH-CLIENT": {
"description": "API key echoed back in response.",
"schema": {
"type": "string"
}
},
"X-HMAC-SIGNATURE": {
"description": "Response body signed with the shared secret key. Required to authenticate the response sender.",
"schema": {
"type": "string"
}
}
},
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/TooManyRequestsErrorResponse"
}
}
}
},
"500": {
"description": "Internal server error",
"headers": {
"Content-Type": {
"description": "Response content type.",
"schema": {
"type": "string",
"example": "application/json"
}
},
"X-AUTH-CLIENT": {
"description": "API key echoed back in response.",
"schema": {
"type": "string"
}
},
"X-HMAC-SIGNATURE": {
"description": "Response body signed with the shared secret key. Required to authenticate the response sender.",
"schema": {
"type": "string"
}
}
},
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/InternalServerErrorResponse"
}
}
}
}
},
"x-d360-narrative-responses": "
Payload compression support info
This endpoint accepts compressed request bodies with Content-Encoding: gzip or Content-Encoding: deflate. Note that this endpoint accepts a plain JSON payload, so compression is not always necessary. For typical session initialization payloads, the bandwidth savings are negligible and the extra CPU cost on the client side outweighs the benefit.
Where compression genuinely helps is when the request includes consent records that carry a text field. The consent text typically contains the full, human-readable consent statement that was shown to the end user, and can be several KB or larger (especially for legal or regulatory consents). In those cases, gzip or deflate can shrink the payload by 60–80%, which is worthwhile.
As a rule of thumb:
If your payload is just a verification block with no consents, or with consents that omit the text field, sending it uncompressed is fine.
If you include one or more consent objects with a non-trivial text field, prefer compression.
Request-body compression is a transport optimization, it does not change the signing contract. Your signature is always computed over the uncompressed JSON body. The server decompresses the payload before validating the signature.
No configuration changes are required for the integration to start using this feature. To use compression, include exactly one of these Content-Encoding values in your request:
gzip (recommended)
deflate
Combined values such as gzip, deflate or deflate, gzip are not supported. br is not supported on this endpoint.
Operation order
Getting the order right is critical. The signature must cover the uncompressed payload, and the compressed payload must decompress back to the exact bytes that were signed.
Build the JSON payload
Serialize the JSON to bytes
Compute the signature over the serialized bytes ← sign BEFORE compressing
Compress the serialized bytes (gzip or deflate)
Send the compressed bytes with the matching Content-Encoding value
If you compress first and then sign the compressed bytes, signature validation will fail.
Request headers
x-auth-client = your API key
x-hmac-signature = Lowercase hex HMAC-SHA256 (64 chars, no prefix) of the uncompressed JSON body
Content-type = application/json
Content-Encoding = gzip (recommended) or deflate
Code examples
The examples below use gzip and include a consent with a long text field, which is the case where compression actually pays off. If you use deflate, keep the same signing flow and set Content-Encoding: deflate with deflate-compressed bytes.
Python
import gzip\nimport hashlib\nimport hmac\nimport json\nimport requests\nAPI_KEY = \"your-api-key\"\nSHARED_SECRET = \"your-shared-secret\"\nBASE_URL = \"https://stationapi.veriff.com\"\n# A realistic consent text is typically much longer than this snippet.\nCONSENT_TEXT = (\n \"I consent to Veriff processing my personal data, including biometric data, \"\n \"for identity verification purposes in accordance with the Privacy Notice. \"\n # ... full legal text continues, often several KB ...\n)\n# Step 1–2: Build and serialize the JSON payload\npayload = {\n \"verification\": {\n \"callback\": \"https://example.com/callback\",\n \"vendorData\": \"customer-123\",\n \"consents\": [\n {\n \"type\": \"general\",\n \"approved\": True,\n \"text\": CONSENT_TEXT,\n \"timestamp\": \"2026-05-08T10:00:00Z\",\n }\n ],\n }\n}\npayload_bytes = json.dumps(payload, separators=(\",\", \":\")).encode(\"utf-8\")\n# Step 3: Sign the UNCOMPRESSED payload\nsignature = hmac.new(\n SHARED_SECRET.encode(\"utf-8\"),\n payload_bytes,\n hashlib.sha256,\n).hexdigest()\n# Step 4: Compress\ncompressed = gzip.compress(payload_bytes)\n# Step 5: Send with Content-Encoding: gzip\nresponse = requests.post(\n f\"{BASE_URL}/v1/sessions\",\n data=compressed, # raw bytes, not json=\n headers={\n \"X-AUTH-CLIENT\": API_KEY,\n \"X-HMAC-SIGNATURE\": signature,\n \"Content-Type\": \"application/json\",\n \"Content-Encoding\": \"gzip\",\n },\n)\nprint(response.status_code, response.json())
Node.js
const crypto = require('crypto');\nconst zlib = require('zlib');\nconst https = require('https');\nconst API_KEY = 'your-api-key';\nconst SHARED_SECRET = 'your-shared-secret';\nconst BASE_URL = 'stationapi.veriff.com';\n// A realistic consent text is typically much longer than this snippet.\nconst CONSENT_TEXT =\n 'I consent to Veriff processing my personal data, including biometric data, ' +\n 'for identity verification purposes in accordance with the Privacy Notice. ' +\n // ... full legal text continues, often several KB ...\n '';\n// Step 1–2: Build and serialize the JSON payload\nconst payload = {\n verification: {\n callback: 'https://example.com/callback',\n vendorData: 'customer-123',\n consents: [\n {\n type: 'general',\n approved: true,\n text: CONSENT_TEXT,\n timestamp: '2026-05-08T10:00:00Z',\n },\n ],\n },\n};\nconst payloadBytes = Buffer.from(JSON.stringify(payload));\n// Step 3: Sign the UNCOMPRESSED payload\nconst signature = crypto\n .createHmac('sha256', SHARED_SECRET)\n .update(payloadBytes)\n .digest('hex');\n// Step 4: Compress\nconst compressed = zlib.gzipSync(payloadBytes);\n// Step 5: Send with Content-Encoding: gzip\nconst req = https.request(\n {\n hostname: BASE_URL,\n path: '/v1/sessions',\n method: 'POST',\n headers: {\n 'X-AUTH-CLIENT': API_KEY,\n 'X-HMAC-SIGNATURE': signature,\n 'Content-Type': 'application/json',\n 'Content-Encoding': 'gzip',\n 'Content-Length': compressed.length,\n },\n },\n (res) => {\n let body = '';\n res.on('data', (chunk) => (body += chunk));\n res.on('end', () => console.log(res.statusCode, body));\n }\n);\nreq.write(compressed);\nreq.end();
Common mistakes
Compressing payloads that don't need it. For small session-creation payloads without a long consent text, the compression overhead is rarely worth it. Reach for compression when consent text or other large string fields push the body well beyond a few KB.
Signing the compressed bytes. The most common integration error. If you compress first and then compute the HMAC over the compressed output, the server will reject the request with a 401. Always sign the uncompressed JSON body.
Encoding/header mismatch. If you send Content-Encoding: gzip or Content-Encoding: deflate but the body is not encoded accordingly, the request fails with a 400. If you are not compressing, omit the Content-Encoding header.
Using json= in your HTTP library with compressed bytes. When sending compressed data, pass compressed bytes as a raw body (data= in Python requests, content= in httpx), not as a JSON parameter. Setting json= causes the HTTP library to re-serialize the payload, which defeats compression and breaks the signature.
Double compression. Do not set Content-Encoding if your HTTP client or proxy is already compressing the request transparently. If in doubt, check the outbound request body and Content-Encoding header.
Using unsupported or combined encodings. Supported values are exactly gzip or deflate. Combined values (for example, gzip, deflate) and other encodings (for example, br) fail with a 415 http error.
Changelog
Date | Description |
|---|
Sep 3, 2026 | address object updated:
person.gender now also accepts male and female
|
June 15, 2026 | hostAppLink parameter added to the request body
|
June 3, 2026 | serviceCoverage parameter added to the request body
|
May 19, 2026 | \"Payload compression\" info added consent object updated:
text string added
timestamp string added
|
Apr 24, 2026 | Headers capitalization harmonized |
Apr 17, 2026 | Typo fixes |
Apr 13, 2026 | New parameters added to support the Metadata Database Verification solution session generation: to person object: fullName, landLinePhoneNumber, partnerLastName, partnerFirstName, marriageDateOfEvent, middleName, secondLastName; to document object: validFrom, validUntil, version, cardType, cardNumber, stateOfIssue, referenceNumber, registrationNumber; to address object: street, houseNumber, postcode, city, state, unit, neighbourhood. Also, new consent types dvs and general to consent.type. |
Mar 18, 2026 | tag parameter info and payload example added
|
Mar 9, 2026 | Documentation updated: parent categories rearranged, intro section expanded, request and response examples added |
Jan 6, 2026 | New parameter occupation added to person object |
Nov 6, 2025 | \"Article Versoning\" renamed to \"Changelog\"
Changelog updated |
Oct 30, 2025 | documentNumberIdentifiers object added
|
Sep 16, 2025 | vrf-integration-id header removed
|
Aug 6, 2025 | Response headers added |
Jul 11, 2025 | Improved the note in the intro section about session creation, and about finding request parameters from Product Guides |
Apr 30, 2025 | - New parameters added to request's verification.person object: email, maritalStatus and isDeceased for registry checks - New header vrf-integration-id added to support the new Flexible API keys solution |
Apr 22, 2025 | proofOfAddress object added to support sending proof of address data over API. This parameter is solution-specific, it is not commonly needed.
|
Mar 12, 2025 | Documentation published |