---
title: "Create verification session | Veriff.com"
slug: "how-to-generate-sessions-manually"
description: "Learn how to use Veriff's API and SDKs for verification sessions, including session creation, handling responses, and managing user data effectively."
tags: ["Create Verification Session", "Verification Session"]
updated: 2026-03-03T09:02:03Z
published: 2026-03-03T09:02:03Z
---
> ## 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 verification session
A verification session is used to pass end-user data to Veriff and receive verification results from Veriff. Current article explains how to start a verification session.
## Create with POST /sessions call
Before you start:
- Refer to**[API prerequisites](https://devdocs.veriff.com/apidocs#prerequisites)[↗]~~~~**and make sure you have all you need to start sending API requests
- Make sure to **check out the**[**Backwards compatible changes**](/v1/docs/backwards-compatible-changes)**list**, to ensure that you are able to handle any updates that Veriff introduces to the payloads
### For API
Make a **[POST /sessions](https://veriff-dev-documentation.document360.io/apidocs/v1sessions)[↗]** call:
- Send `verification` object to **https://<**BaseURL**>/v1/sessions** (*required)
- Include the `Content-Type application/json` header (*required)
- Include the `X-AUTH-CLIENT`**header** containing your integration's API key (*required)
- Include the end-user's data/media you have collected (refer to the **Request properties explained** in [POST /sessions](https://veriff-dev-documentation.document360.io/apidocs/v1sessions)[↗]) (optional)
- Include the `vendorData`/`endUserId` parameter (strongly recommended)
Check the response .json and**record the unique session ID** in `verification.id`, required for webhooks and for identifying the session later on.
#### Minimum sample request
The example below uses placeholder data.
```bash
curl -X POST \
--url 'dummyBaseUrl/v1/sessions/' \
-H 'Content-Type: application/json' \
-H 'X-AUTH-CLIENT: API-KEY' \
-d '{
"verification": {},
}
}'
```
#### Expanded sample request
The example below uses placeholder data.
```bash
curl -X POST \
--url '/v1/sessions/' \
-H 'Content-Type: application/json' \
-H 'X-AUTH-CLIENT: API-KEY' \
-d '{
"verification": {
"callback": "https://veriff.com",
"person": {
"firstName": "John",
"lastName": "Smith",
"idNumber": "123456789"
},
"document": {
"number": "B01234567",
"type": "PASSPORT",
"country": "EE"
},
"address": {
"fullAddress": "Lorem Ipsum 30, 13612 Tallinn, Estonia"
},
"vendorData": "11111111",
"endUserId": "fa820aba-019f-455a-ae81-cfca8075bc3f",
"consents": [
{
"type": "ine",
"approved": true
}
]
}
}'
```
#### Sample response
The example below uses placeholder data.
```json
{
"status": "success",
"verification": {
"id": "b27afb60-1455-4927-b155-0260ffe0947a",
"url": "https://....",
"vendorData": "2bf528f7-4b9c-44f0-b928-fdc7afc5ca1b",
"endUserId": "fa820aba-019f-455a-ae81-cfca8075bc3f",
"host": "https://....veriff.com",
"status": "created",
"sessionToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....."
}
}
```
### For native or web SDK
Make a [POST /sessions](https://veriff-dev-documentation.document360.io/apidocs/v1sessions)[↗] call:
- Send `verification` object to `https://<BaseURL>/v1/sessions`
- Include the Content-Type `application/json` header
- Include the `X-AUTH-CLIENT header` containing your integration's API key
- Include the callback URL in `verification.callback` for Redirect end-users
- Include the `vendorData` parameter
Check the response .json and**record**:
- **Unique session ID** in `verification.id`, required for webhooks and for identifying the session later on
- **Unique sessionToken** in `verification.sessionToken`
- **Unique session URL**in `verification.url` , required to bring the end-users to verification flow
*→ See the specific SDKs guide in*[*SDK Guides*](/v1/docs/sdk-guide)*section for more info about how to start the verification session*
#### Minimum sample request
The example below uses placeholder data.
```bash
curl -X POST \
--url 'dummyBaseUrl/v1/sessions/' \
-H 'Content-Type: application/json' \
-H 'X-AUTH-CLIENT: API-KEY' \
-d '{
"verification": {
"callback": "https://veriff.com",
"vendorData": "2bf528f7-4b9c-44f0-b928-fdc7afc5ca1b"
},
}
}'
```
#### Sample response
The example below uses placeholder data.
```json
{
"status": "success",
"verification": {
"id": "b27afb60-1455-4927-b155-0260ffe0947a",
"url": "https://....",
"vendorData": "2bf528f7-4b9c-44f0-b928-fdc7afc5ca1b",
"endUserId": "fa820aba-019f-455a-ae81-cfca8075bc3f",
"host": "https://....veriff.com",
"status": "created",
"sessionToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....."
}
}
```
---
## Create with JavaScript SDK
You can use the [JavaScript SDK](/v1/docs/javascript-sdk-1) to generate a session URL for your **web flow**.
*→ See sample implementation for Javascript at*[*https://github.com/Veriff/js-integration-demo*](https://github.com/Veriff/js-integration-demo)**[↗]
---
## Manually
It is possible to **manually generate a**verification session**in the**Veriff Customer Portal. This option can be used to **test** or **debug** sessions, or as a **manual fallback** option.
The manual option creates a link and a QR code that you can share with the end-user.
1. Go to **Veriff Customer Portal**
2. Click on the **All verifications** on the left hand menu
3. Click on the **Add Verification**button
4. Find and open the relevant integration
5. Fill in the **User first name**, **User last name**
6. Click **Generate** **Verification**
7. Share the session by copying the link or the QR
---
## Cap on the session creation rate
Note that there is a maximum limit to how many sessions you can create in an integration:
- Enterprise customer: 600 sessions per minute
- Self-Serve customer: 30 sessions per minute
---
## Verification session statuses
The session **status** indicates the progress of the verification session, signalling **the stage where the end-user’s verification process** currently is.
*→ See the*[*Verification session status codes (table)*](/v1/docs/verification-session-status-codes-table)*article for technical info about how Veriff notifies you about the status change and how different session statuses can affect the flow*
*→ See the*[*Meanings of various verification statuses and decisions*](https://help.veriff.com/en/articles/3250231-meanings-of-various-verification-statuses-and-decisions)*[↗]**article in Veriff Knowledge Base for additional info (you need to log in to Veriff Customer Portal to access the article)*
| Status | What does this mean? |
| --- | --- |
| `created` | A session has been created for the end-user. They have not yet entered the verification flow. |
| `started` | The end-user has started their session and landed in Veriff’s verification flow. No decision is available yet. |
| `submitted` | End-user’s required data has been submitted. No decision is available yet. |
| `approved` | Positive: end-user was verified. The verification process is complete. Accessing the` sessionURL` again will show that nothing is to be done here. |
| `declined` | Negative: end-user has not been verified. The verification process is complete. Either it was a fraud case or some other severe reason that the end-user could not be verified. You should investigate the session further and read the [Granular reason codes (table)](/v1/docs/granular-reason-codes). If you decide to give the end-user another try, you need to create a new session using the POST /sessions endpoint. |
| `resubmission_requested` | Resubmission has been requested. The verification process has not been completed. Something was missing from the end-user, and they need to go through the flow once more. The same `sessionURL` should be used for this purpose. You can investigate the session further and read the [Granular reason codes (table)](/v1/docs/granular-reason-codes). |
| `expired` | Verification has been expired because the end-user never accessed the verification (a session expires 7 days after being created unless it gets a conclusive decision before that). The verification process is complete. If you decide to give the end-user another try, you need to create a new session using the POST /sessions endpoint. |
| `abandoned` | Verification has been abandoned because the end-user started the verification session but never finished it (a session is abandoned 7 days after being created unless it gets a conclusive decision before that). The verification process is complete. If you decide to give the end-user another try, you need to create a new session using the POST /sessions endpoint. |
| `review` | This status is issued whenever the automation engine could not issue a conclusive decision and the verification session needs to be reviewed by a human on your side. Note that in order to receive this status, it must be specifically configured and enabled for you integration. |
---
## About verification session expiry
All verification sessions expire after 7 days.
- Sessions in `created` status will move to `expired`
- Sessions in `started` status will move to `abandoned`
---
## Changelog
| Date | Description |
| --- | --- |
| Mar 3, 2026 | Note about placeholder data added to code samples |
| Sep 15, 2025 | Info about `vrf-integration-id` header sending requirement removed |
| Jun 19, 2025 | Sections added: [Verification session statuses](/v1/docs/how-to-generate-sessions-manually#verification-session-statuses) [About verification session expiry](/v1/docs/how-to-generate-sessions-manually#about-verification-session-expiry) |
| Jun 6, 2025 | Header “Article versioning” renamed to “Changelog” |
| May 16, 2025 | Info about the maximum limit on session creation rate added |
| Apr 30, 2025 | Flexible API keys info added to **For API**and **For native or web SDK** sections |
| Mar 12, 2025 | Documentation published |
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.
**User of Veriff customer's solution**, the person who goes through the verification flow (aka "end-user flow").
A "base address" for the specific API that you are using. **Used to create the API URL** value for API requests.
You can find it in**Veriff Customer Portal**> **All** **Integrations >***Integration name***> API keys** tab (you need to be logged in).
A **unique identifier of an integration.**
A **required parameter for authentication: i**t is used to create the `X-AUTH-CLIENT header` value for **API requests**.
Occasionally, referred to as the "API public key" or "Publishable key".
You can find it in**Veriff Customer Portal**> **API keys** page (you need to be logged in).
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 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 **unique identifier of a verification session**. It is automatically created as soon as you create a session.
In the **API requests' context**, one verification session comprises many steps (uploading data, uploading images, getting a decision, etc.). You can call several endpoints using the same **session ID**, to get all kinds of different data from that specific session.
You can find its value in the **response payload** of your **POST /sessions API request**, in the `verification.id` parameter.
A **mandatory header field** in API requests, **required to identify the request sender**. Its value is the **API key**.
An environment created according to customer's needs to carry out, manage and observe verifications.
You can find the list of your integrations in **Veriff Customer Portal**> **All** **Integrations**page (you need to be logged in).
Page where the **end-user is directed after completing the verification flow**. This page does not contain any verification or decision info.
**Default value** is visible in Veriff Customer Portal > Integration's Settings tab. **Override** in Customer Portal or via POST /sessions request's `verification.callback` field (API override wont change the value in Portal).
Find **current value** in POST /sessions response as `verification.callback`.
Also referred to as **redirect URL**.
**Session-specific token for a verification session**.
You can find its value in the response payload of the POST /sessions, as `verification.sessionToken`.
It is a **JSON Web Token (JWT)** that **consists of the session ID and the session creation timestamp**. It should always **have the variable max length type**and must be **able to accept****data up to 8KB**.
A legacy element, for backward compatibility.
This where the end-user is directed to go through the verification flow, and it is **unique for each verification session**.
It is a combination of the `base URL` and the `sessionToken`, created as soon as a verification session is created. You can find its value in the response payload of your POST /sessions call, as `verification.url`.
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**.
## Related
- [Integrations](/how-to-create-an-integration.md)
- [JavaScript SDK](/javascript-sdk-1.md)
- [Verification session decisions](/verification-session-decisions.md)
- [Verification session status codes (table)](/verification-session-status-codes-table.md)
- [Verification session decision codes (table)](/verification-session-decision-codes-table.md)