---
title: "Proof of Address Capture | Veriff.com"
slug: "proof-of-address-capture"
description: "Capture end-user’s document for subsequent verification steps. Available via native SDK, web flow, and API."
tags: ["Document Capture", "Proof of Address"]
updated: 2025-03-07T13:19:18Z
published: 2025-03-07T13:19:18Z
canonical: "devdocs.veriff.com/proof-of-address-capture"
---

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

# Proof of Address Capture

Veriff’s Proof of Address Capture (PoA Capture) feature **only** **captures the submitted document**. No further analysis is performed.

It is available via API, web flow, and native SDKs.

> [!NOTE]
> Contact your **solutions engineer** for info and configuration.

---

## Prerequisites

- You have an [integration set up](/v1/docs/how-to-create-an-integration) with Veriff
- Your Solutions Engineer has **enabled the PoA Capture for the integration**
- If using the API, you are ready to send Veriff images of the end-user’s proof of address document

---

## Flow overview

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

### Use via SDKs

1. Generate a verification session using the authentication integration tokens (check the [POST /sessions](https://devdocs.veriff.com/apidocs/v1sessions) endpoint in the API reference)
2. Capture end-user’s PoA document images with Veriff’s SDKs
  1. Send the end-user through the verification flow to capture the image (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 of their face

### Use via API

**1. Create a session using the POST /sessions call**

**1.1 Include the API URL and mandatory headers**

```plaintext
POST {baseURL}/v1/sessions
Type: object
Headers:
       X-AUTH-CLIENT: string (required) = API key
       Content-Type: application/json
```

**1.2 Add the following data (minimum payload)**

- `verification`: `object` Verification object*. You can send an empty object, or include the following to improve the results:
  - vendorData: `string`
  - endUserId: `string`

*Mandatory parameter

**Request payload sample**

```curl
curl -X POST \
  --url '/v1/sessions/' \
  -H 'Content-Type: application/json' \
  -H 'X-AUTH-CLIENT: API-PUBLIC-KEY' \
  -d '{
    "verification": {
        "vendorData": "11111111"
    }
}'
```

*→ See the [POST /sessions](https://devdocs.veriff.com/apidocs/v1sessions) endpoint documentation for further details about how to start a session*

**2. Make a POST /sessions/{sessionId}/media request**

You can use this endpoint to **send several images**, but you need to **upload them one at a time**.

Also, if you post several image files, make sure that the value of `image.context` parameter of the image relevant to the PoA Capture flow is `document-front`, otherwise the PoA Capture flow will not work.

**2.1 Include the API URL and mandatory headers**

```plaintext
POST {baseURL}/v1/sessions/{sessionId}/media
Type: object
Headers:
       X-AUTH-CLIENT: string (required) = API key
       X-HMAC-SIGNATURE: string (required) = sessionId signed with the shared secret key
       Content-Type: application/json
```

**2.2 Add the following data into the minimum payload**

- `image`: `object`*
  - `context`: `string`* In this case, it must be `document-front`
  - `content`: `string`* Base64 encoded image (.jpg, .jpeg, .png, .heif, .heic, .webp and .pdf formats are supported)

*Required parameter

**Request payload sample**

```curl
curl -X POST \
  --url '/v1/sessions/aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7/media' \
  -H 'Content-Type: application/json' \
  -H 'X-AUTH-CLIENT: API-PUBLIC-KEY' \
  -H 'X-HMAC-SIGNATURE: 034c6da2bb31fd9e6892516c6d7b90ebe10f79b47cfb3d155d77b4d9b66e1d53' \
  -d '{
    "image": {
        "context": "document-front",
        "content": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA+.../9fgAEAKcxisFjVfn0AAAAASUVORK5CYII="
    }
}'
```

*→ See the [POST /sessions/{sessionId}/media](https://devdocs.veriff.com/apidocs/v1sessionsidmedia-3) endpoint documentation for further details about how to send media files*

**3. Update the session status to `submitted` using the PATCH /sessions/{sessionId} call**

**3.1 Include the API URL and mandatory headers**

```plaintext
PATCH {baseURL}/v1/sessions/{sessionId}
Type: object
Headers:
       X-AUTH-CLIENT: string (required) = API key
       X-HMAC-SIGNATURE: string (required) = sessionId signed with the shared secret key
       Content-Type: application/json
```

**3.2 Add the following data (minimum payload)**

- `verification`: `object`*
  - `status`: `string`* Status of the verification session you are patching the session into, always `submitted`

*Required parameter

**Request payload sample**

```curl
curl -X PATCH \
  --url '/v1/sessions/fd5c1563-1d23-4b1a-ae46-7ba429927ed8' \
  -H 'Content-Type: application/json' \
  -H 'X-AUTH-CLIENT: API-PUBLIC-KEY' \
  -H 'X-HMAC-SIGNATURE: dd994f70b1150ae012f9c1d6d20adf7ed69780044835d39de20b00ffae0660a0' \
  -d '{
    "verification": {
      "status": "submitted"
    }
}'
```

Once done, an [event webhook](/v1/docs/event-webhook) with `submitted` status will be sent.

1. Now you can use the following API calls to query the document info:

- [GET /sessions/{sessionId}/media](/v1-api/apidocs/v1sessionsidmedia-2) to get a list of media objects and address media with the `sessionId`
- [GET /attempts/{attemptId}/media](https://veriff-dev-documentation.document360.io/apidocs/v1attemptsidmedia-1) to get a list of media objects and address media with the attempt ID
- [GET /media/{mediaId}](https://veriff-dev-documentation.document360.io/apidocs/v1mediaid-1) to get a media file with the `mediaId`

## Find uploaded images

After the images have been **submitted**, you can query them via API or see them in Veriff Customer Portal, by opening the session on the **All Verifications** page.

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

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.

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.

An **address** that allows you to access an API and its various features. It consists of a `BaseURL` and an `endpoint`.

Occasionally, also referred to as the "API URL path".

**Mandatory elements** in the **API requests**, containing the metadata.

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.

An **UUID v4** of a specific **attempt**, found in decision webhook as `attemptId` parameter, or in **GET /sessions/{sessionId}/attempts** response as `verification.id` parameter.

An **"attempt" is one step inside a verification session**, e.g., uploading required data and getting a decision. An **"attempt" can be made several times** during a verification session. This means that calling the GET /sessions/{sessionId}/attempts can return several `verification` objects, each one with a unique `id` value.

## Related

- [Getting Started](/getting-started.md)
- [Integrations](/how-to-create-an-integration.md)
- [Create verification session](/how-to-generate-sessions-manually.md)
- [Webhooks Guide](/webhooks-guide.md)
- [Codes](/codes.md)