---
icon: person
label: User lifecycle
order: 850
expanded: false
---

# User lifecycle: enrollment → authentication

This guide describes the recommended way to model the full lifecycle of a returning user in VerifEye's Redirect — **first visit** (enrollment) and **return visits** (authentication) — using a **single Verification project**.

## Key concept: the first verification call *is* the enrollment

!!!info
When a user is sent through a Face Recognition verifier in `UniqueMatchVerification` or `MatchVerification` mode with a never-before-seen `reExternalId`, the face embedding is automatically stored under that identifier as part of the verification.

**There is no separate enrollment endpoint or step.** On every subsequent call with the same `reExternalId`, the same verifier performs a 1:1 match against the stored embedding.
!!!

This is the property that makes a single-project lifecycle possible: the same Verification can both onboard a brand-new user and authenticate a returning one — the verifier knows the difference from the state of the face collection.

## Recommended pattern: single project + session overrides

The single-project pattern uses **one** Verification, configured with the full enrollment-time verifier set, and uses **session-level overrides** to disable verifiers that are only relevant on the first visit.

!!!warning Do not split one user base across multiple Verifications
Each Verification has its **own face collection scope** — a user known to one Verification is unknown to another. Creating multiple Verifications for the **same user base** (for example, one for enrollment and a separate one for authentication) is **not recommended**: the second Verification will not see the enrollment from the first and will silently auto-enroll the user again, defeating the separation.

Use a **single Verification** with session-level overrides instead, as described below.
!!!

**Verification configuration (one-time setup):**

- **Liveness**: `Verification`
- **Face Recognition**: `UniqueMatchVerification` (or `MatchVerification` — see [Verifier choice](#verifier-choice-uniquematchverification-vs-matchverification) below)
- **Age**: `ThresholdVerification` or `CalculationOnly` as needed
- **Gender**: `CalculationOnly` as needed
- **`AllowVerifierOverrides`**: `true` — required for the return-visit overrides to take effect

[!ref text="See Session Override configurations for the full list of override keys"](/redirect/verification-configurations/#session-override-configurations)

### First visit vs. return visit

The two flows use the **same Verification URL**; only the session-level query string differs.

| | First visit (enrollment) | Return visit (authentication) |
|---|---|---|
| **Verification project** | Same project | Same project |
| **Session URL parameters** | `reExternalId=user-123` | `reExternalId=user-123`<br/>`reDisableLivenessVerifier=true`<br/>`reDisableAgeVerifier=true`<br/>`reDisableGenderVerifier=true` |
| **Liveness** | runs | skipped |
| **Face Recognition** | **enrolls** the new face under `user-123` | **matches** against the stored embedding for `user-123` |
| **Age / Gender** | runs (returns `reAge`, `reGender`) | skipped |
| **Typical result parameters** | `reLivenessResult=passed`<br/>`reFaceRecognitionResult=passed`<br/>`reAgeVerificationResult=passed`, `reAge=…`<br/>`reGenderVerificationResult=passed`, `reGender=…` | `reFaceRecognitionResult=passed` |

!!!warning
Do **not** disable the Face Recognition verifier on the return visit (`reDisableFaceRecognitionVerifier=true`) — that is the verifier performing the authentication. The other verifiers (liveness, age, gender) are the ones safe to disable.
!!!

The Verification URL itself must be signed by your backend in both cases (see the [Security page](/redirect/security/#incoming-signed-verification-url-request-integrity)). The session-level override parameters are part of the signed payload, so they cannot be tampered with by the end user.

## Verifier choice: `UniqueMatchVerification` vs. `MatchVerification`

Both modes auto-enroll on first use and perform a 1:1 match on subsequent visits. The difference is whether **cross-identifier uniqueness** is enforced.

| | `UniqueMatchVerification` | `MatchVerification` |
|---|---|---|
| Auto-enrolls on first `reExternalId` | yes | yes |
| 1:1 match on return visit | yes | yes |
| Fails if the same face is already stored under a **different** `reExternalId` | yes | no |
| Use when | You also need to prevent the same person from registering twice under different IDs (e.g., one-per-person promotions, KYC). | You only need to authenticate a known user and don't care about cross-ID uniqueness (e.g., re-authentication for an existing account). |

## Common pitfalls

- **`AllowVerifierOverrides` must be enabled on the Verification.** If it is `false`, the `reDisable…Verifier` query parameters on the return visit are silently ignored and the full enrollment flow runs every time.
- **Use the same `reExternalId` for the same user across visits.** This identifier is the only thing linking the first and the return visit; without a stable value, the system treats each visit as a new user and auto-enrolls a fresh embedding.
- **Do not disable Face Recognition on the return visit.** Disabling Liveness / Age / Gender is the intended override; disabling Face Recognition removes the authentication step itself.

## Related

- [Concept — Verification, scope, and face collections](/redirect/concept/)
- [Verification configurations — verifier modes and session overrides](/redirect/verification-configurations/)
- [Parameters — `reExternalId` and the session override keys](/redirect/parameters/)

---

*Last updated: 2026-05-19*