---
title: "Verification session status codes (table) | Veriff.com"
slug: "verification-session-status-codes-table"
description: "Understand verification session statuses, including codes like `approved`, `declined`, and `resubmission_requested`, to enhance user experience with Veriff."
updated: 2025-06-19T11:21:16Z
published: 2025-06-19T11:21:16Z
---

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

# Verification session status codes (table)

***Additional info about verification session statuses***

**What are session statuses?**

Verification session status indicate the **progress of the verification session**, indicating the stage where the session currently is. **Veriff notifies about the following stages**, sending a descriptive label and a session code:

- `started` (7001)
- `submitted` (7002)
- `approved` (9001)
- `declined` (9102)
- `resubmission_requested` (9103)
- `expired` (9104)
- `abandoned` (9104)
- `review` (9121)

Veriff **does not notify**about the following status: `created`

**Fetch session status**

The session status is available in the `verification.status` parameter in:

- [Decision webhook](/v1/docs/decision-webhook) payload
- <meta charset="utf-8">[POST /sessions](https://veriff-dev-documentation.document360.io/apidocs/v1sessions)[↗] response
- <meta charset="utf-8">[GET /sessions/{sessionId}/attempts](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsidattempts-1)[↗] response
- <meta charset="utf-8">[GET sessions/{sessionId}/decision](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsiddecision-1)[↗] response

→ *See also 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 more info <meta charset="utf-8">(you need to log in to Veriff Customer Portal to access the article).*

## Verification session status codes

The session **status codes** indicate the progress of the verification session, signalling **the stage where the end-user’s verification process** currently is.

This info is sent back in:

- `action` and `code` strings in the event webhook
- `verification.status` and `verification.code` strings in the decision webhook

| Status | Code | Sent via | What does this mean? |
| --- | --- | --- | --- |
| `created` | Veriff does not notify about this status | Veriff does not notify about this status | A session has been created for the end-user. They have not yet entered the verification flow. |
| `started` | 7001 | Event webhook | The end-user has started their session and landed in Veriff’s verification flow. No decision is available yet. |
| `submitted` | 7002 | Event webhook | End-user’s required data has been submitted. No decision is available yet. |
| `approved` | 9001 | Decision webhook | Positive: end-user was verified. The verification process is complete. Accessing the` sessionURL` again will show that nothing is to be done here. |
| `declined` | 9102 | Decision webhook | 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` | 9103 | Decision webhook | 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` | 9104 | Decision webhook | 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` | 9121 | Decision webhook | 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. |

Responses 9001, 9102, 9121 and 9104 are **conclusive responses**. The session is closed and the `sessionURL` is not available for the end-user.

Response 9103 is an **inconclusive response**. The session remains open until you receive one of the above conclusive responses. The session is re-opened for the end-user, accepting a new attempt.

*→ 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 more info <meta charset="utf-8">(you need to log in to Veriff Customer Portal to access the article)*

### Status: `resubmission_requested`

If you are using the API solution, then when the verifications receive the `resubmission_requested` status from Veriff, it is strongly advised that you **inform the end-user about the reasons for the verification failure** and **provide suggestions on how to improve** their next attempt. This communication can be conducted through email, SMS, and/or within your platform to ensure better visibility.

For resubmitted verification attempts where certain elements were missing or the quality of the submission was subpar, a new attempt is generated and made available through the same session URL. It is important to use the same session URL for verification attempts made by the same end-user.

### Status: `review`

This status is not sent by default. You need to have an agreement with Veriff to receive it, and it must be configure for you integration.

The `review` status means that **somebody from your end** should take a look at the session and decide to approve or decline the end-user.

### 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 |
| --- | --- |
| Jun 19, 2025 | [About verification session expiry](/v1/docs/verification-session-status-codes-table#about-verification-session-expiry) section added Added a note about the verification status: `created` |
| Mar 12, 2025 | Documentation published |