---
title: "Essential Plan | Veriff.com"
slug: "essential-plan-full-auto"
description: "Explore the Self-Serve Essential Plan technical setup side."
tags: ["Automated Service", "Automatic Setup Supported", "Essential Plan", "Full Auto Webhook", "Identity Verification", "Self-Serve Plans"]
updated: 2025-07-08T10:54:33Z
published: 2025-07-08T10:54:33Z
---

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

# Essential Plan

This is a **fully automated identity verification service**, where the end-user submits images of their ID document and themselves (document + selfie). The solution can be used via **native SDKs, web flow (aka web SDKs) and the API**.

> [!NOTE]
> The Essential Plan solution uses it own separate [Full Auto webhook](/v1/docs/full-auto-webhook) to send `insights`, `extractions` and `decisionScore` about the session.
> 
> Decision webhook is not used.

The system analyses the images, verifies the end-user and returns the following info:

- Decision
- Decision score
- Extraction details
- Session insights

All the info about sessions done in Self-Serve: Essential Plan integration is returned via specific **Full Auto webhook**, which needs to be **configured separately** in the Veriff Customer Portal. The **decision webhook is not used**.

The **results of the verification** can also be **viewed in the Veriff Customer Portal** to make a decision about the end-user.

Because all this detailed info is returned, **Full Auto sessions do not return reason codes**.

---

## Prerequisites

- You have an [integration set up](/v1/docs/how-to-create-an-integration) with Veriff
- You have configured the **Full Auto webhook** to get responses from Veriff (see the [Webhooks](/v1/docs/webhooks-guide) section for info)
- You have created the endUserId / vendorData parameter for your end-user and are ready to send it
- If using the API, it is highly recommended to send the session and device data for better fraud detection

---

## Flow overview

The flow is a bit different, depending on the method you are using to verify your end-users with Veriff.

### Use via SDK

1. Generate a verification session using the `API keys` and the `baseURL` of your integration (see the <meta charset="utf-8">[API Documentation and API Reference](https://devdocs.veriff.com/apidocs)[↗] how to find these)
2. Capture end-user’s document and selfie images with Veriff’s SDKs
  1. Send the end-user through the verification flow to capture the images (using the preferred [Veriff SDK](/v1/docs/sdk-guide))
  2. You need the session URL generated in step 1 to use the SDKs (found in response payload as `verification.url`)
3. Session will be submitted automatically once the end-user takes and submits necessary images
4. Receive the results from Veriff via [Full Auto webhook](/v1/docs/full-auto-webhook)

### Use via API

1. Generate a verification session using the `API keys` and the `baseURL` of your integration (see the <meta charset="utf-8">[API Documentation and API Reference](https://devdocs.veriff.com/apidocs)[↗] how to find these)
  1. Ensure you send the `endUserId` / `vendorData` parameter
  2. Veriff strongly recommends you collect and send additional session/device data via <meta charset="utf-8">[POST sessions/{sessionid}/collected-data](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsidcollected-data-1)[↗] for improved fraud detection
2. Use your image-capturing method, or prepare previously collected end-user document and selfie images
3. Upload end-user's media via <meta charset="utf-8">[POST /sessions/{sessionId}/media](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsidmedia-3)[↗]
4. Specify the `image.context` as appropriate for the image (see the [context types](/v1/docs/context-types-image-video-1) (table) for more info)
5. Patch the session `status` to `submitted` using the <meta charset="utf-8">[PATCH /sessions/{sessionId}](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsid-2)[↗]
6. 
  1. Check the decision data and/or session related info from the [Full Auto webhook](/v1/docs/full-auto-webhook) and/or query the data from the [GET sessions/{sessionId}/decision/fullauto](/v1/docs/essential-plan-full-auto#api-call) endpoint

---

## Find decision and/or session related info

You can get the data from three sources:

- Receive the full auto webhook
- Query the results via GET /v1/sessions/{sessionId}/decision/fullauto
- View the session in Veriff Customer Portal

### Webhook payload

*→ See the*[*Full Auto webhook*](https://devdocs.veriff.com/docs/full-auto-webhook#sample-request)*documentation*

### API call

You can use the GET /v1/sessions/{sessionId}/decision/fullauto endpoint, which contains the same data as the decision webhook, but also additional details.

> [!NOTE]
> Make sure to add the mandatory query parameter version=1.0.0 to the API URL:
> 
> `GET /v1/sessions/{sessionId}/decision/fullauto?version=1.0.0`

#### Response: high-level overview

This section gives a **very high-level overview** of the API response body. The response body is very similar to the Full Auto webhook payload: the endpoint response matches the `data.verification` object of the webhook payload.

Log in to the Veriff Customer Portal to see the Full Auto webhook sample payload here: [Full Auto Webhook](https://help.veriff.com/en/articles/8529223-full-auto-webhook-sample) [↗].

**API response properties explained**

- `decisionScore`: `number | null` A float number, shows how confident the system is that the session is genuine. Higher number indicates higher confidence. The number is rounded up to two decimal places.
- `decision`: `string` Shows system’s **suggestion** of what to do with the session, one of: `approved`, `declined`, `resubmission_requested`, `abandoned`, `expired`
- `person`: `object` Data extracted from the document about the person. Contains additional objects with specific data that has been extracted
- `document`: `object` Data extracted from the document about the document. Contains additional objects with specific data that has been extracted
- `insights`: `array | null` Array of pieces of metadata that help explain the decision

```json
{
    "decisionScore": 0.96,
    "decision": "approved",
    "person": {
      ...
    },
    "document":{
      ...
    },
    "insights":[
      {
         ...
      },
    ]
}
```

---

### Veriff Customer Portal

You can find the verification session related info, including the decision, in the Veriff Customer Portal, under the **Verifications** 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*

---

## Changelog

| Date | Description |
| --- | --- |
| Jul 8, 2025 | Added “/v1/ to public API endpoint address for better clarity |
| Jun 6, 2025 | Heading “Article versioning” changed to “Changelog” |
| Mar 31, 2025 | Article renamed to “Essential Plan” Improvements to intro section Added `endUserId` data |
| Mar 12, 202z5 | Documentation published |

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.

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

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

The data that you send when you make an API request, or that you receive when you get a response.

## Related

- [Getting Started](/getting-started.md)
- [Integrations](/how-to-create-an-integration.md)
- [Create verification session](/how-to-generate-sessions-manually.md)
- [Full Auto webhook](/full-auto-webhook.md)
- [Codes](/codes.md)