---
title: "Intro to the API | Veriff.com"
slug: "quick-guide-of-idv-using-the-api"
description: "Quick and lightweight introduction to Veriff's REST API for end-user verification."
updated: 2025-06-06T13:56:55Z
published: 2025-06-06T13:56:55Z
canonical: "devdocs.veriff.com/quick-guide-of-idv-using-the-api"
---

> ## 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.

# Intro to the API

> [!NOTE]
> See [API Documentation and API Reference](https://devdocs.veriff.com/apidocs) for detailed info about Veriff APIs

Opt for using the **Application Programming Interface (API)** solution if you want to **collect** the end-user's data and/or **media yourself via your own solution**, and then **use Veriff's API endpoints** to **pass us relevant data for verification**.

Note that collecting end-user's data beforehand or during the flow is **optional**, as Veriff can extract this data from the media sent to us.

## Quick overview of the steps

1. [Create an integration](/v1/docs/how-to-create-an-integration)
2. [Set up webhooks](/v1/docs/webhooks-guide)
3. [Create a verification session](/v1/docs/how-to-generate-sessions-manually) to get the session ID
  1. Veriff strongly recommends you send the `vendorData`/`endUserId` (see below)
4. Using the **session ID**, pass end-user's media via [POST /sessions/{sessionId}/media](https://devdocs.veriff.com/apidocs/v1sessionsidmedia-3)
5. Patch the session to `submitted` using [PATCH /sessions/{sessionId}](https://devdocs.veriff.com/apidocs/v1sessionsid-2)
6. Wait for Veriff to verify the end-user
7. Veriff returns the decision via a [webhook](/v1/docs/webhooks-guide)

> [!TIP]
> `vendorData` **parameter**
> 
> Veriff **strongly recommends** (and on occasions require) you create a **unique identifier for your end-user, store it and send it to Veriff**. You can use the `vendorData` parameter to send an identifier that is max 1,000 characters long and contains only non-semantic data that can not be resolved or used outside your systems or environments.
> 
> `vendorData` is a fixed value that **cannot be changed**. It is used to tie together a specific end-user and their session(s). Veriff returns it unmodified in webhooks and API response payloads, or as `null` if not provided.
> 
> `vendorData` is **mandatory for Cross Links check and Velocity Abuse check** (Fraud solutions); and an **alternative to the `endUserId` parameter** in Biometric Authentication solution, if you are using some non-UUID format to create unique identifiers.

> [!TIP]
> `endUserId` **parameter**
> 
> Veriff **strongly recommends** (and on occasions require) you **create a unique identifier for your end-user**, store it and send it to Veriff. If you are using the UUID format to create and store the identifiers, you should use the `endUserId` parameter to send it to Veriff.
> 
> This identifier is used to tie together a specific end-user and their session(s). Veriff returns it unmodified in webhooks and API response payloads, or as `null` if not provided.
> 
> The `endUserId` parameter is a good alternative to the `vendorData` parameter in Biometric Authentication solution.

## API session lifecycle diagram

When verifying via API:

- Customer decides wether to collect end-user’s data and media before or after creating the session
- Session ID aka `verification.id` is the unique identifier of the session that needs to be included in all the API calls that are done for that session

![Flowchart illustrating the flow of data between the end-user, customer, and Veriff during a verification process.](https://cdn.document360.io/5c26138b-b1e9-404e-a2e4-c83a49245be7/Images/Documentation/API_flow_diagram.jpg?sv=2026-02-06&spr=https&st=2026-11-08T02%3A54%3A14Z&se=2026-11-08T03%3A54%3A14Z&sr=c&sp=r&sig=b1tBhLoJOJMFU3At92Q%2FfASP6xgCxs6hhd9c%2FbeyAcM%3D)

The diagram above illustrates an end-to-end integration verification process between three entities: end-user, customer, and Veriff.

| Step | End-User | Customer | Veriff |
| --- | --- | --- | --- |
| 1 | Starts verification process and provides document and selfie images | Collects images of end-user's document and selfie (if relevant) |  |
| 2 |  | Creates session by sending POST request to "/sessions" |  |
| 3 |  |  | Returns session ID in `verification.id` parameter |
| 4a |  | Uploads media via POST to "sessions/{sessionId}/media" |  |
| 4b |  | Updates session status to "submitted" via PATCH to "/sessions/{sessionId}" |  |
| 5 |  |  | Session is verified (internal process) |
| 6a |  | Receives decision | Sends decision to customer via webhook |
| 6b |  | Optionally uses GET request to "/sessions/{sessionId}/decision" to query more detailed data | Provides detailed verification data when requested |

The diagram uses dashed vertical lines to represent the timeline for each entity and horizontal arrows to show the direction of communication between them. Green horizontal bars represent the end-user providing documents/selfie in step 1 and Veriff verifying the session in step 5.

---

## Changelog

| Date |  |
| --- | --- |
| Jun 6, 2025 | Header “Article versioning” renamed to “Changelog” |
| Mar 31, 2025 | Session flow diagram updated Alt text updated |
| Mar 12, 2025 | Documentation published |

**User of Veriff customer's solution**, the person who goes through the verification flow (aka "end-user flow").

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.

## Related

- [Integrations](/how-to-create-an-integration.md)