> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.id.me/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.id.me/_mcp/server.

# Consent before verification

> Learn how the consent before verification policy setting collects user consent at the start of the ID.me flow, before identity verification begins.

By default, users see the ID.me consent screen as the last step of a flow, after they finish identity verification. **Consent before verification** is a policy setting that moves the consent screen to the beginning of the flow, so users agree to share their information with your application before any verification steps start.

## Why use it

* **Consent is on record immediately.** ID.me records consent as soon as the user selects **Allow**, even if the user never finishes verification. With the default flow, a user who abandons verification part way through never reaches the consent screen, so no consent exists for that user.
* **Earlier data sharing.** Because consent exists from the start, ID.me can begin sharing account events about that user with your application, such as account suspensions or email changes, without waiting for verification to complete.
* **Transparency for users.** Users see who receives their information, and agree, before they submit documents or a selfie.
* **Less wasted effort.** Users who would decline find out immediately and return to your application, without going through verification first.

## How it works

When consent before verification is enabled on a policy, the user flow changes as follows.

#### User signs in

The user signs in to ID.me and completes any required multi-factor authentication.

#### User reviews the consent screen

Before verification begins, ID.me shows the consent screen listing your application and the attributes it requests.

#### User selects Allow or Deny

* **Allow:** ID.me records the user's consent and continues into verification. The user is **not** sent back to your application yet.
* **Deny:** ID.me returns the user to your application with a denial. No verification is started.

#### User completes verification

The user completes the verification steps required by the policy.

#### User returns to your application

When verification finishes, ID.me sends the user back to your application and shares the requested attributes. The user is **not** asked for consent a second time.

## Behavior details

### Returning users

Consent is recorded per user and per application, so the consent screen appears whenever a user has no consent on record for your application. This applies even if the user has already verified with ID.me or was preverified for another application.

Users who already have consent on record for your application are handled based on the policy's consent mode:

| Consent mode          | Behavior for a returning user                                                                        |
| --------------------- | ---------------------------------------------------------------------------------------------------- |
| Normal, Sign-in, Skip | Not asked again.                                                                                     |
| Enforce               | Asked once per sign-in transaction. The user is not asked a second time within the same transaction. |

If the attributes your policy requests change after a user consents, the stored consent no longer matches and the user is asked again.

### Events tracked

`consent.allow` and `consent.deny` events are tracked the same way as in the default flow.

## Requirements and limitations

> **Not available for all policies**
>
> Consent before verification is available only for policies where the list of shared attributes is fixed in the policy configuration (static consent).

* **Dynamic consent policies are not supported.** Dynamic consent builds the attribute list from the user's verified data, which does not exist before verification. These policies continue to show consent after verification.
* **White-label flows are not supported.** White-label flows are unchanged.
* **The setting is off by default.** Policies without the setting enabled see no change in behavior.
* **Consent records can exist for unverified users.** Because consent is collected first, your application may be eligible to receive account events for users who consented but never completed verification. Account for these users in any logic that assumes a consenting user is also verified.

## Configuration

Consent before verification is configured per policy. To enable it for a policy, contact your ID.me solution consultant or email [partnersupport@id.me](mailto:partnersupport@id.me).