--- title: "Intro to the API | Veriff.com" slug: "quick-guide-of-idv-using-the-api" description: "Find a quick intro to using Veriff public API for end-user verification." updated: 2025-06-06T13:56:55Z published: 2025-06-06T13:56:55Z --- > ## 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://veriff-dev-documentation.document360.io/apidocs/v1sessionsidmedia-3)[↗] 5. Patch the session to `submitted` using [PATCH /sessions/{sessionId}](https://veriff-dev-documentation.document360.io/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) 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)