---
title: "ProBet Database Verification"
slug: "pro-bet-database-verification"
description: "Pro Bet Database Verification ensures compliance with Brazil's betting regulations, preventing fraud through automated user screening and API integration."
updated: 2026-01-15T11:07:04Z
published: 2026-01-15T11:07:04Z
---
> ## 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.
# ProBet Database Verification
| Available via API | Available via SDK | Needs configuration on Veriff’s side | Needs a separate integration | Needs a separate webhook |
| --- | --- | --- | --- | --- |
| ✅ | ❌ | ✅ | ✅ | ❌ |
**Pro Bet Database Verification** validates users against Brazil's betting exclusion registries to ensure gambling regulatory compliance. Key benefits for customers include regulatory compliance for licensed Brazilian gambling operators, fraud prevention through government registry cross-referencing, and automated screening of betting restrictions.
**Pro Bet Database Verification** is available via **API**. The solution can be:
- an add-on to your document + selfie IDV or document-only IDV, or
- used separately as a standalone check
All session-related **info is returned via** **decision webhook** and can be **polled from different API endpoints**. The results of the verification can also be viewed in the Veriff Customer Portal, on session’s page → Webhooks tab.
If any **data** was **extracted from the document**, this data is provided in the decision **webhook payload** and **GET /decision endpoint’s response payload**.
> [!NOTE]
> Contact your **solutions engineer** for info and configuration.
---
## Prerequisites
- You have an [integration set up](/v1/docs/how-to-create-an-integration) with Veriff
- The feature is configured for that integration **by your Solutions Engineer**
- You have configured the [decision webhook](/v1/docs/decision-webhook) to get responses from Veriff (see the how-to in webhooks’ [Set up webhooks](https://devdocs.veriff.com/docs/webhooks-guide#set-up-webhooks) section)
- Ensure that you are ready to collect and **send** Veriff your **end-user’s data**: CPF (Brazilian Tax ID) and date of birth.
- Because the solution is available only via API:
- Veriff **strongly recommends** you collect and send **additional device/session data** for improved fraud mitigation.
- Veriff **strongly recommends** that you **create and send** us the endUserId or vendorData.
### Key terminology
| **Term** | Description |
| --- | --- |
| **CPF number** | *Cadastro de Pessoas Físicas*, Brazilian individual taxpayer registry 11-digit number |
| **ProBet** | Brazil's registry of individuals restricted from betting activities |
| **PIA** | *Pessoas Impedidas de Apostar,* individuals involved in betting administration |
| **PEP** | Politically Exposed Persons i.e., government officials with potential conflicts of interest |
| **CNPJ** | Brazilian company tax identification number |
---
## End-user data sources
The “end-user data sources” refer to different origins from which the end-user’s information can be collected for database verification. There are two data sources: **document data** and **initData**.
#### Document data
This is **data** that is **extracted** from the **end-user’s document**. Includes information extracted from Brazilian identity documents (driver's licenses, ID cards). If using document extraction flow, **the CPF number and date of birth are extracted** from Brazilian documents and **passed automatically** to the ProBet validation.
#### InitData
This is **data that you provide** when creating a verification session, i.e. the parameters you specify in the [POST /sessions](https://devdocs.veriff.com/apidocs/v1sessions) request. Includes information like names, date of birth, address, phone number, ID number, gender etc.
InitData takes precedence over document extraction if both are present.
Parameters that can be sent via initData:
- CPF number via `verification.person.idNumber`
- Date of birth via `verification.person.dateOfBirth`
---
## Flow overview
### Use via API
#### Standalone Pro Bet Database Verification verification
Use when you only need to verify **Pro Bet Database Verification** without collecting document images.
1. Generate a verification session using the API keys and the `baseURL` of your **Pro Bet Database Verification** integration (see the [API Documentation and API Reference](https://devdocs.veriff.com/apidocs)[↗] how to find these)
- Make sure to pass the mandatory `verification.person.idNumber` (CPF number) and `verification.person.dateOfBirth` parameters.
- Veriff strongly recommends you create and send the `endUserId` or `vendorData`.
- Veriff strongly recommends you collect and send additional session/device data via [POST sessions/{sessionid}/collected-data](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsidcollected-data-1)[↗] for improved fraud detection.
**Session creation bash example**
```bash
curl -X POST \
--url 'https://stationapi.veriff.com/v1/sessions/' \
-H 'Content-Type: application/json' \
-H 'X-AUTH-CLIENT: API-KEY' \
-d '{
"verification": {
"callback": "https://yourwebsite.com/webhook",
"person": {
"idNumber": "12345678901",
"dateOfBirth": "1990-01-15"
}
}
}'
```
**Session creation json example**
```json
{
"verification": {
"callback": "https://yourwebsite.com/webhook",
"person": {
"idNumber": "12345678901",
"dateOfBirth": "1990-01-15"
}
}
}
```
1. Patch session status to `submitted` status using [PATCH /sessions/{sessionId}](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsid-2)[↗] call.
**Session update bash example**
```bash
curl -X PATCH \
--url 'https://stationapi.veriff.com/v1/sessions/{sessionId}' \
-H 'Content-Type: application/json' \
-H 'X-AUTH-CLIENT: API-KEY' \
-H 'X-HMAC-SIGNATURE: 034c6da2bb31fd9e6892516c6d7b90ebe10f79b47cfb3d155d77b4d9b66e1d53' \
-d '{
"status": "submitted"
}'
```
**Session update json example**
```json
{
"status": "submitted"
}
```
1. Check the decision data and/or session related info from the decision webhook ([example below](/v1/docs/pro-bet-database-verification#webhook-payload)) and/or query the data from the GET /sessions/{sessionId}/decision endpoint ([example below](/v1/docs/pro-bet-database-verification#api-call)). Solution-specific overview of what to expect is provided below in [Solution-specific parameters](/v1/docs/pro-bet-database-verification#solutionspecific-parameters) section.
#### Pro Bet Database Verification with document verification
1. Generate a verification session using the API keys and the `baseURL` of your **Pro Bet Database Verification** integration ((see the [API Documentation and API Reference](https://devdocs.veriff.com/apidocs)[↗] how to find these)
1. The `field_document_number` check is required if using the document verification flow.
2. Veriff strongly recommends you create and send the `endUserId` or `vendorData`.
3. Veriff strongly recommends you collect and send additional session/device data via [POST sessions/{sessionid}/collected-data](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsidcollected-data-1)[↗] for improved fraud detection.
**Session creation bash example**
```bash
curl -X POST \
--url 'https://stationapi.veriff.com/v1/sessions/' \
-H 'Content-Type: application/json' \
-H 'X-AUTH-CLIENT: API-KEY' \
-d '{
"verification": {
"callback": "https://yourwebsite.com/webhook"
}
}'
```
**Session creation json example**
```json
{
"verification": {
"callback": "https://yourwebsite.com/webhook"
}
}
```
1. Use your image-capturing method, or prepare previously collected **document image(s)**
2. Upload the end-user's media via `POST /sessions/{sessionId}/media` call
- Specify the `image.context` as appropriate for the image (see [Context types (image, video)](/v1/docs/context-types-image-video-1) for more info about image context types).
**Media upload bash example**
```bash
curl -X POST \
--url 'https://example.com/v1/sessions/{sessionId}/media' \
-H 'Content-Type: application/json' \
-H 'X-AUTH-CLIENT: API-KEY' \
-H 'X-HMAC-SIGNATURE: 034c6da2bb31fd9e6892516c6d7b90ebe10f79b47cfb3d155d77b4d9b66e1d53' \
-d '{
"image": {
"context": "document-front",
"content": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEAYABgAAD..."
}
}'
```
**Media upload json example**
```json
{
"image": {
"context": "document-front",
"content": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEAYABgAAD..."
}
}
```
1. Patch session status to `submitted` status using [PATCH /sessions/{sessionId}](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsid-2)[↗] call.
**Session update bash example**
```bash
curl -X PATCH \
--url 'https://example.com/v1/sessions/{sessionId}' \
-H 'Content-Type: application/json' \
-H 'X-AUTH-CLIENT: API-KEY' \
-H 'X-HMAC-SIGNATURE: 034c6da2bb31fd9e6892516c6d7b90ebe10f79b47cfb3d155d77b4d9b66e1d53' \
-d '{
"status": "submitted"
}'
```
**Session update json example**
```json
{
"status": "submitted"
}
```
1. Check the decision data and/or session related info from the decision webhook ([example below](/v1/docs/pro-bet-database-verification#webhook-payload)) and/or query the data from the GET /sessions/{sessionId}/decision endpoint ([example below](/v1/docs/pro-bet-database-verification#api-call)). Solution-specific overview of what to expect is provided below in [Solution-specific parameters](/v1/docs/pro-bet-database-verification#solutionspecific-parameters) section.
---
## Find decision and/or session related info
You can get the data from three sources:
- Receive the decision webhook ([example below](/v1/docs/pro-bet-database-verification#webhook-payload))
- Query the results via GET /sessions/{sessionId}/decision ([example below](/v1/docs/pro-bet-database-verification#api-call))
- View the session in Veriff Customer Portal.
Note that the decision webhook and GET /sessions/{sessionId}/decision payloads are identical.
### Solution-specific parameters
Info related to **Pro Bet Database Verification** is returned in `additionalVerifiedData.proBet` **object**. This object is structured into two main sections: `validations` and `registryResponse` objects.
This object contains ProBet registry validation results and detailed registry response data, including PEP status, artist information, betting administration records, and final betting eligibility determination.
#### `validations` object
This object contains the results of various rule checks run against the user. Each key represents a specific rule. Every rule inside the validations object shares the following structure:
- `result`: `string` Shows the outcome of the validation, usually `success` or `failure`
- `reasons`: `array | null` A list of strings explaining why the validation failed. If result is `success`, this is usually `null` or empty.
To see the full explanation of parameters inside the objects, see the [webhook payload explanation](/v1/docs/brazilian-cadastro-unico-database-verification#request-properties-explained) section below.
| Parameter | Description |
| --- | --- |
| `processing`**object** | Indicates if the internal processing of the validation check was successful |
| `isUserDataValid`**object** | Checks if the input data provided (CPF, Name, etc.) follows the correct format |
| `isNotOnPia`**object** | Checks if the user is **NOT listed** in the PIA registry (Persons involved in Betting Administration, e.g., Lottery owners). A `failure` here means they **ARE restricted**. |
| `isNotOnProBet`**object** | Checks if the **user is NOT**in the general Pro Bet **exclusion list.** A `failure` here means they **ARE on the exclusion list.** |
#### `registryResponse` object
This object presents detailed data regarding specific groups of people from registries.
To see the full explanation of parameters inside the objects, see the [webhook payload explanation](/v1/docs/brazilian-cadastro-unico-database-verification#request-properties-explained) section below.
| Parameter | Description |
| --- | --- |
| `pepData` **object** | Details regarding Politically Exposed Persons. In many jurisdictions, PEPs are subject to stricter scrutiny regarding financial transactions, including betting. |
| `artistData` **object** | Details regarding artists, athletes, or public figures who might have restrictions on betting (e.g., to prevent match-fixing or influence) |
| `piaData` **object** | Details regarding the PIA (*Pessoa Impedida de Apostar*) |
| `influencerData` **object** | Details regarding digital influencers. Some regulations restrict influencers from betting or require disclosure. |
| `scoreData` **object** | The final computed result based on all the data above |
#### **Example with only solution-specific parameters**
```json
{
"verifications": {
"additionalVerifiedData": {
"proBet": {
"validations": {
"processing": {
"result": "success",
"reasons": null
},
"isUserDataValid": {
"result": "success",
"reasons": null
},
"isNotOnPia": {
"result": "failure",
"reasons": [
"User is on PIA registry"
]
},
"isNotOnProBet": {
"result": "failure",
"reasons": [
"User is on Pro Bet registry"
]
}
},
"registryResponse": {
"pepData": {
"name": "MARIA SILVA SANTOS",
"role": "SECRETARIO GERAL",
"organization": "SECRETARIA NACIONAL DE DESENVOLVIMENTO REGIONAL",
"exerciseStartDate": "25/07/2023",
"exerciseEndDate": "",
"pepValidityDate": ""
},
"artistData": {
"cpf": "12345678901",
"name": "MARIA SILVA SANTOS",
"artisticName": "MARIA SILVA SANTOS",
"occupation": "CANTORA"
},
"piaData": {
"isInRegistry": true,
"cnpj": "12345678901234",
"companyName": "LOTERICA BOM DESTINO LTDA",
"type": "CASAS LOTERICAS"
},
"influencerData": {
"artisticName": "MARIA SILVA SANTOS",
"socialMediaUrl": "",
"areaOfActivity": "INFLUENCER"
},
"scoreData": {
"isAllowedToBet": false
}
}
}
}
}
}
```
If a document was used in the verification, all the info that the system is able to extract from the document is returned in `verification.person` and `verification.document` objects.
### Webhook payload
> [!NOTE]
> Below is an **example and an explanation of the decision webhook** payload, showing only the **mandatory parameters** for a **Pro Bet Database Verification session**.
>
> Depending on your integration configuration, the payload may contain additional parameters. To find more info about those parameters, see the [decision webhook](/v1/docs/decision-webhook) documentation.
#### Sample request
```json
{
"status": "success",
"verification": {
"id": "12df6045-3846-3e45-946a-14fa6136d78b",
"attemptId": "00bca969-b53a-4fad-b065-874d41a7b2b8",
"vendorData": "12345678",
"endUserId": "a1b2c35d-e8f7-6d5e-3cd2-a1b2c35db3d42",
"status": "declined",
"code": 9102,
"reason": "User is on PIA registry",
"reasonCode": 570,
"decisionTime": "2025-12-12T13:00:00.000+02:00",
"acceptanceTime": "2025-12-12T12:00:00.000+02:00",
"submissionTime": "2025-12-12T12:05:00.000000+02:00",
"person": {
"firstName": "MARIA",
"lastName": "SILVA SANTOS",
"dateOfBirth": "1990-01-15",
"gender": "F",
"nationality": "BR",
"idNumber": "12345678901",
"yearOfBirth": "1990",
"placeOfBirth": "SAO PAULO"
},
"document": {
"number": "AB123456",
"type": "ID_CARD",
"country": "BR",
"state": "SP"
},
"additionalVerifiedData": {
"proBet": {
"validations": {
"processing": {
"result": "success",
"reasons": null
},
"isUserDataValid": {
"result": "success",
"reasons": null
},
"isNotOnPia": {
"result": "failure",
"reasons": ["User is on PIA registry"]
},
"isNotOnProBet": {
"result": "failure",
"reasons": ["User is on Pro Bet registry"]
}
},
"registryResponse": {
"pepData": {
"name": "MARIA SILVA SANTOS",
"role": "SECRETARIO GERAL",
"organization": "SECRETARIA NACIONAL DE DESENVOLVIMENTO REGIONAL",
"exerciseStartDate": "25/07/2023",
"exerciseEndDate": "",
"pepValidityDate": ""
},
"artistData": {
"cpf": "12345678901",
"name": "MARIA SILVA SANTOS",
"artisticName": "MARIA SILVA SANTOS",
"occupation": "CANTORA"
},
"piaData": {
"isInRegistry": true,
"cnpj": "29872262000128",
"companyName": "LOTERICA BOM DESTINO LTDA",
"type": "CASAS LOTERICAS"
},
"influencerData": {
"artisticName": "MARIA SILVA SANTOS",
"socialMediaUrl": "",
"areaOfActivity": "INFLUENCER"
},
"scoreData": {
"isAllowedToBet": false
}
}
}
},
"comments": [],
},
"technicalData": {
"ip": "192.168.1.1"
}
}
```
#### Request properties explained
- `status`: `string` Status of the response
- `verification`: `object` Verification request decision object. `null` if decision is not available yet
- `id`: `string` UUID v4 which identifies the verification session
- `attemptId`: `string` UUID v4 of the attempt which received a status (as shown in `verification.status` field)
- `vendorData`: `string | null` The unique identifier that you created for your end-user. `null` if not specified
- `endUserId`: `string | null` The `UUID` that you created for your end-user. `null` if not specified
- `status`: `string` Session verification status (`approved`, `declined`, `resubmission_requested`, `review`, `expired`, `abandoned`)
- `code`: `integer` Verification session decision code, one of `9001`, `9102`, `9103`, `9104`, `9121`. For more info, see the verification session decision codes
- `reason`: `string | null` Human-readable decline reason
- `reasonCode`: `integer | null` Reason code of the failed verification. For more info, see the [possible codes for a failed verification](/v1/docs/verification-session-decision-codes-table)
- `decisionTime`: `string | null` Timestamp of the decision, represented as `UTC YYYY-MM-DDTHH:MM:SS.SSS+Timezone Offset` (ISO 8601)
- `acceptanceTime`: `string` Timestamp of the session generation, represented as `UTC YYYY-MM-DDTHH:MM:SS.SSS+Timezone Offset` (ISO 8601)
- `submissionTime`: `string` Timestamp of when the session was submitted, represented as `UTC YYYY-MM-DDTHH:MM:SS.SSSSSS+Timezone Offset` (ISO 8601)
- `person`: `object` Data about the verified person
- `firstName`: `string | null` Person's first name as written on the document
- `lastName`: `string | null` Person's last name as written on the document
- `dateOfBirth`: `string` Person's date of birth, represented as `YYYY-MM-DD`
- `gender`: `string | null` Person's gender, represented as M or F, or `null` if not present
- `nationality`: `string | null` Person's nationality, represented as ISO 3166 `alpha-2` or `alpha-3` number
- `idNumber`: `string | null` National identification number (CPF)
- `yearOfBirth`: `string | null` Person's year of birth, represented as `YYYY`
- `placeOfBirth`: `string | null` Person's place of birth
- `document`: `object` Verified document
- `number`: `string | null` Document number, `[a-zA-Z0-9]` characters only
- `type`: `string | null` Document type, one of `PASSPORT`, `ID_CARD`, `RESIDENCE_PERMIT`, `DRIVERS_LICENSE`, `VISA`, `OTHER`
- `country`: `string | null` Document issuing country, represented as ISO 3166 `alpha-2` code
- `state`: `string | null` Document issuing state, represented as ISO 3166 `alpha-2` or `alpha-3` code
- `additionalVerifiedData`: `object` Container for solution-specific data
- `proBet`: `object` ProBet validation results container
- `validations`: `object` Validation rule results
- `processing`: `object` Processing validation result
- `result`: `string` Validation outcome (`success`, `failure`)
- `reasons`: `array | null` Explanations for failure (`null` or empty if `result` value is `successful`)
- `isUserDataValid`: `object` User data format validation
- `result`: `string` Validation outcome
- `reasons`: `array | null` Explanations for failure (`null` or empty if `result` value is `successful`)
- `isNotOnPia`: `object` PIA registry check (negative logic)
- `result`: `string` Validation outcome
- `reasons`: `array | null` Explanations for failure (`null` or empty if `result` value is `successful`)
- `isNotOnProBet`: `object` ProBet registry check (negative logic)
- `result`: `string` Validation outcome
- `reasons`: `array | null` Explanations for failure (`null` or empty if `result` value is `successful`)
- `registryResponse`: `object` Detailed registry data
- `pepData`: `object` Politically exposed person (PEP) information
- `name`: `string` Full name of PEP
- `role`: `string` Public office or role held
- `organization`: `string` Government body or organization
- `exerciseStartDate`: `string` Role start date
- `exerciseEndDate`: `string` Role end date
- `pepValidityDate`: `string` PEP validity date
- `artistData`: `object` Artist/public figure information
- `cpf`: `string` Brazilian Tax ID
- `name`: `string` Legal name
- `artisticName`: `string` Stage or public name
- `occupation`: `string` Profession or role
- `piaData`: `object` Betting administration registry information
- `isInRegistry`: `boolean` Indicates whether found in PIA registry
- `cnpj`: `string` Company tax identification number
- `companyName`: `string` Legal company name
- `type`: `string` Business category
- `influencerData`: `object` Digital influencer information
- `artisticName`: `string` Social media name
- `socialMediaUrl`: `string` Primary social media URL
- `areaOfActivity`: `string` Influence category
- `scoreData`: `object` The final computed result based on all the data above
- `isAllowedToBet`: `boolean` Indicates whether the end-user is allowed to bet
- `comments`: `array` *(Deprecated) Always returns empty []*
- `technicalData`: `object` Technical data object
- `ip`: `string | null` IP of the device from which the verification was made
### API call
> [!NOTE]
> Below is an **example and an explanation** of the **GET /decision API call payload**, showing only the **mandatory parameters** for a **Pro Bet Database Verification session**.
>
> Depending on your integration configuration, the payload may contain additional parameters. To find more info about those parameters, see the [GET sessions/{sessionId}/decision](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsiddecision-1)[↗] documentation.
#### Sample response
```json
{
"status": "success",
"verification": {
"id": "12df6045-3846-3e45-946a-14fa6136d78b",
"attemptId": "00bca969-b53a-4fad-b065-874d41a7b2b8",
"vendorData": "12345678",
"endUserId": "a1b2c35d-e8f7-6d5e-3cd2-a1b2c35db3d42",
"status": "declined",
"code": 9102,
"reason": "User is on PIA registry",
"reasonCode": 570,
"decisionTime": "2025-12-12T13:00:00.000+02:00",
"acceptanceTime": "2025-12-12T12:00:00.000+02:00",
"submissionTime": "2025-12-12T12:05:00.000000+02:00",
"person": {
"firstName": "MARIA",
"lastName": "SILVA SANTOS",
"dateOfBirth": "1990-01-15",
"gender": "F",
"nationality": "BR",
"idNumber": "12345678901",
"yearOfBirth": "1990",
"placeOfBirth": "SAO PAULO"
},
"document": {
"number": "AB123456",
"type": "ID_CARD",
"country": "BR",
"state": "SP"
},
"additionalVerifiedData": {
"proBet": {
"validations": {
"processing": {
"result": "success",
"reasons": null
},
"isUserDataValid": {
"result": "success",
"reasons": null
},
"isNotOnPia": {
"result": "failure",
"reasons": ["User is on PIA registry"]
},
"isNotOnProBet": {
"result": "failure",
"reasons": ["User is on Pro Bet registry"]
}
},
"registryResponse": {
"pepData": {
"name": "MARIA SILVA SANTOS",
"role": "SECRETARIO GERAL",
"organization": "SECRETARIA NACIONAL DE DESENVOLVIMENTO REGIONAL",
"exerciseStartDate": "25/07/2023",
"exerciseEndDate": "",
"pepValidityDate": ""
},
"artistData": {
"cpf": "12345678901",
"name": "MARIA SILVA SANTOS",
"artisticName": "MARIA SILVA SANTOS",
"occupation": "CANTORA"
},
"piaData": {
"isInRegistry": true,
"cnpj": "29872262000128",
"companyName": "LOTERICA BOM DESTINO LTDA",
"type": "CASAS LOTERICAS"
},
"influencerData": {
"artisticName": "MARIA SILVA SANTOS",
"socialMediaUrl": "",
"areaOfActivity": "INFLUENCER"
},
"scoreData": {
"isAllowedToBet": false
}
}
}
},
"comments": [],
},
"technicalData": {
"ip": "192.168.1.1"
}
}
```
#### Response properties explained
- `status`: `string` Status of the response
- `verification`: `object` Verification request decision object. `null` if decision is not available yet
- `id`: `string` UUID v4 which identifies the verification session
- `attemptId`: `string` UUID v4 of the attempt which received a status (as shown in `verification.status` field)
- `vendorData`: `string | null` The unique identifier that you created for your end-user. `null` if not specified
- `endUserId`: `string | null` The `UUID` that you created for your end-user. `null` if not specified
- `status`: `string` Session verification status (`approved`, `declined`, `resubmission_requested`, `review`, `expired`, `abandoned`)
- `code`: `integer` Verification session decision code, one of `9001`, `9102`, `9103`, `9104`, `9121`. For more info, see the verification session decision codes
- `reason`: `string | null` Human-readable decline reason
- `reasonCode`: `integer | null` Reason code of the failed verification. For more info, see the [possible codes for a failed verification](/v1/docs/verification-session-decision-codes-table)
- `decisionTime`: `string | null` Timestamp of the decision, represented as `UTC YYYY-MM-DDTHH:MM:SS.SSS+Timezone Offset` (ISO 8601)
- `acceptanceTime`: `string` Timestamp of the session generation, represented as `UTC YYYY-MM-DDTHH:MM:SS.SSS+Timezone Offset` (ISO 8601)
- `submissionTime`: `string` Timestamp of when the session was submitted, represented as `UTC YYYY-MM-DDTHH:MM:SS.SSSSSS+Timezone Offset` (ISO 8601)
- `person`: `object` Data about the verified person
- `firstName`: `string | null` Person's first name as written on the document
- `lastName`: `string | null` Person's last name as written on the document
- `dateOfBirth`: `string` Person's date of birth, represented as `YYYY-MM-DD`
- `gender`: `string | null` Person's gender, represented as M or F, or `null` if not present
- `nationality`: `string | null` Person's nationality, represented as ISO 3166 `alpha-2` or `alpha-3` number
- `idNumber`: `string | null` National identification number (CPF)
- `yearOfBirth`: `string | null` Person's year of birth, represented as `YYYY`
- `placeOfBirth`: `string | null` Person's place of birth
- `document`: `object` Verified document
- `number`: `string | null` Document number, `[a-zA-Z0-9]` characters only
- `type`: `string | null` Document type, one of `PASSPORT`, `ID_CARD`, `RESIDENCE_PERMIT`, `DRIVERS_LICENSE`, `VISA`, `OTHER`
- `country`: `string | null` Document issuing country, represented as ISO 3166 `alpha-2` code
- `state`: `string | null` Document issuing state, represented as ISO 3166 `alpha-2` or `alpha-3` code
- `additionalVerifiedData`: `object` Container for solution-specific data
- `proBet`: `object` ProBet validation results container
- `validations`: `object` Validation rule results
- `processing`: `object` Processing validation result
- `result`: `string` Validation outcome (`success`, `failure`)
- `reasons`: `array | null` Explanations for failure (`null` or empty if `result` value is `successful`)
- `isUserDataValid`: `object` User data format validation
- `result`: `string` Validation outcome
- `reasons`: `array | null` Explanations for failure (`null` or empty if `result` value is `successful`)
- `isNotOnPia`: `object` PIA registry check (negative logic)
- `result`: `string` Validation outcome
- `reasons`: `array | null` Explanations for failure (`null` or empty if `result` value is `successful`)
- `isNotOnProBet`: `object` ProBet registry check (negative logic)
- `result`: `string` Validation outcome
- `reasons`: `array | null` Explanations for failure (`null` or empty if `result` value is `successful`)
- `registryResponse`: `object` Detailed registry data
- `pepData`: `object` Politically exposed person (PEP) information
- `name`: `string` Full name of PEP
- `role`: `string` Public office or role held
- `organization`: `string` Government body or organization
- `exerciseStartDate`: `string` Role start date
- `exerciseEndDate`: `string` Role end date
- `pepValidityDate`: `string` PEP validity date
- `artistData`: `object` Artist/public figure information
- `cpf`: `string` Brazilian Tax ID
- `name`: `string` Legal name
- `artisticName`: `string` Stage or public name
- `occupation`: `string` Profession or role
- `piaData`: `object` Betting administration registry information
- `isInRegistry`: `boolean` Indicates whether found in PIA registry
- `cnpj`: `string` Company tax identification number
- `companyName`: `string` Legal company name
- `type`: `string` Business category
- `influencerData`: `object` Digital influencer information
- `artisticName`: `string` Social media name
- `socialMediaUrl`: `string` Primary social media URL
- `areaOfActivity`: `string` Influence category
- `scoreData`: `object` The final computed result based on all the data above
- `isAllowedToBet`: `boolean` Indicates whether the end-user is allowed to bet
- `comments`: `array` *(Deprecated) Always returns empty []*
- `technicalData`: `object` Technical data object
- `ip`: `string | null` IP of the device from which the verification was made
### Veriff Customer Portal
You can find the verification session related info, including the decision, in the **Veriff Customer Portal** → **Session page → Webhooks** **tab.**
→ *See*[*Review verification in Veriff Customer Portal*](/v1/docs/how-to-review-verification-in-veriff-customer-portal)*about how to view the session info in the Veriff Customer portal*
---
## Status and reason codes
For an `approved` session, see:
- `verification.code` about verification session decision code, one of `9001`, `9102`, `9103`, `9104`, `9121`.
- `verification.status` about verification status, one of `approved`, `declined`, `resubmission_requested`, `expired`, `abandoned`.
If the **Pro Bet Database Verification** session was `declined` or `resubmission_requested`, you can find additional information by checking:
- `verification.reason` for the reason why the verification failed.
- `verification.reasonCode` for reason code of the failed verification and cross-reference it with [Granular reason codes (table)](/v1/docs/granular-reason-codes).
| `verification``.status` | `verification.reasonCode` | `verification.reason` | What does it mean? |
| --- | --- | --- | --- |
| `declined` | 570 | IS_ON_PIA | End-user is in betting administration registry. This is mandatory block for gambling operators. |
| `declined` | 570 | IS_ON_PRO_BET | User is on ProBet exclusion list.This is mandatory block for gambling operators. |
| `declined` | 529 | INVALID_CPF | CPF format is invalid. Ensure 11-digit number without punctuation. |
| `declined` | 529 | INVALID_DATE_OF_BIRTH | Date of birth format is invalid. Ensure ISO 8601 YYYY-MM-DD format |
| `declined` | 529 | BIRTHDATE_DIFFERS_FROM_REGISTRY | Date of birth does not match registry data. Ensure that correct date of birth has been entered. |
| `declined` | 566 | UNAVAILABLE_REGISTRY_PROVIDER | Registry service unavailable |
| `declined` | 566 | TIMEOUT_ERROR | Registry query timed out |
| `declined` | 566 | INTERNAL_ERROR | Internal processing error |
The table above aims to list the most common reasons why you may see the `decline` reason for a **Pro Bet Database Verification** session. However, the session may be declined due to a reason that is not inherently **Pro Bet Database Verification** verification related (e.g. uploaded document’s quality is low). In that case, to find info about the codes you are seeing, refer to:
- [Verification session status codes (table)](/v1/docs/verification-session-decision-codes-table)
- [Verification session decision codes (table)](/v1/docs/verification-session-decision-codes-table)
- [Granular reason codes (table)](/v1/docs/granular-reason-codes)
---
## Additional information
### Best practices
1. **CPF format validation**: CPF numbers must be exactly 11 digits without punctuation (dashes or dots). Invalid formats will cause immediate validation failure with code `529`. Implement early validation on your side to ensure proper formatting before session creation.
2. **Date of Birth format validation**: Date of birth must be in ISO 8601 format (`YYYY-MM-DD`). Implement early validation on your side to ensure proper formatting before session creation, because invalid formats will cause immediate validation failure with code `529`.
3. **Document image quality**: ensure that end-user’s document image is of good quality. This will reduce the possibility of session going to `resubmission_requested`.
4. **Error handling**: Implement proper error handling for all possible validation results (format issues, registry timeouts and issues, etc.)
5. **Session declined due to third-party provider issues**: Implement proper session handling flow when possibly legitimate end-user’s session is declined due to the third-party service provider having issues, as indicated by session code `566`.
6. **Webhook security**: Secure your webhook endpoint and verify request signatures.
7. **User experience**: Provide clear feedback to users about validation results.
8. **Ensure**[**backwards compatibility**](/v1/docs/backwards-compatible-changes) for webhooks and API connections.
---
## Changelog
| Date | Description |
| --- | --- |
| Jan 15, 2026 | Indentation in payload examples and explanations updated |
| Dec 16, 2025 | Minor updates to the text formatting |
| Dec 15, 2025 | Documentation published |
Veriff customer back-office, a dashboard where you can see your end-users' verification data.
Depending on your setup, you may be required to access the environment via station.veriff.com or hub.veriff.com. Always **check your sign-up email** and make sure that you **log in via correct address**.
A UUID-format unique identifier ([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}) created by you for your end-user to link an end-user to their session(s). Cannot be resolved outside your environment.
Veriff stores it only for identity verification and returns it unchanged in webhooks/API responses or as `null` if not provided.
Strongly recommended if you already use UUID identifiers. Works as an alternative to `vendorData` in Biometric Authentication solution.
A custom unique identifier (max 1,000 characters) created by you, containing only non-semantic data that can't be resolved outside your systems.
Veriff returns it unchanged in webhooks/API responses or as `null` if not provided.
It's referred to as "unique identifier" in Customer Portal and cannot be changed once set.
Required for Fraud solutions (Cross Links check and Velocity Abuse check) and serves as an alternative to `endUserId` in Biometric Authentication when using non-UUID identifiers.
A session during which the end-user is verified. It starts when a session is created, it can contain several attempts (i.e. steps of uploading media, sending additional data etc.) and it ends when a conclusive decision (“approved”, “declined”, “expired”/”abandoned”) is granted.
Each verification session receives an unique ID, aka the **session ID**, which can be added to the API URL when making API requests.