---
icon: light-bulb
label: Concept
order: 1000
expanded: false
---

This section describes the core concepts you will encounter when integrating with VerifEye's Redirect.

## Verification session

A **verification session** represents a single end-user attempt.

- A session has a unique identifier (`reVerificationSessionId` in the final redirect URL).
- The session aggregates the individual verifier outcomes into an overall verification result.

## Verification

A **Verification** represents a named, configurable verification experience. It defines how the verification flow must work (rules, enabled verifiers, thresholds, UX options, etc.), and it may also reference or contain a **face collection** used by the Face Recognition verifier.

A verification contains the following configurations:

- Verifier configurations
- Redirect configurations
- Result parameter configurations
- Security configurations
- Session Override configurations

### One-time setup (create once, reuse many times)

The API endpoints that create or modify a Verification are **one-time setup** operations and should be clearly labeled in the documentation as such. A Verification must typically be created **only once per face-collection scope**, either:

- via the developer/admin portal (recommended for most teams), or
- via a **single programmatic call** from a secure backend/service.

After creation, the same Verification configuration must be **reused** for all end-user sessions in that scope by referencing its `verification_id` (or `verification_name`, depending on the API design).

### What “scope” means (and why it matters)

A Verification is a configuration object that is tied to a particular **face collection scope**, which depends on your use case:

- **Login / authentication for an entire user base:**
You typically create **one Verification** for the whole user base (one shared face collection scope), and reuse it for every login attempt.

- **Project- or campaign-based access control (separate populations):**
You create **one Verification per project/campaign scope**, for example:
- - protecting a specific survey on a survey platform (each survey can have its own scope), or
- - a limited-stock promotion (e.g., “Discounted shoes” campaign), where you want to admit new participants only until inventory lasts—each campaign/promo can be isolated via its own face collection scope and Verification.

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

For an enrollment-then-authentication flow for the same user base, use a **single Verification** with session-level overrides. See the [User lifecycle](/redirect/user-lifecycle/) guide.
!!!

### Security guidance (must be created server-side)

Creating a Verification is a **privileged administrative action** and must be performed from a **trusted, secure environment** (backend, admin service, or portal). It must **not** be created by the end user on the client side.

If a user could create or control their own Verification, they could potentially influence the verification behavior (e.g., choose weaker settings, point to a different face collection, or otherwise manipulate the process). Therefore:

- **Only admin/backend credentials** should be allowed to call “create/update Verification” endpoints.
- Client applications should only receive a reference to an existing Verification (e.g., `verification_id`) and use it to start verification sessions.

!!!
Every configuration can be easily set either in the Developer Console or via VerifEye Service API.

[!ref target="blank" text="Developer Console"](https://verifeye-console.realeyes.ai/)
[!ref text="VerifEye Service API"](/rest-api/verifeye-service-api)

!!!

[!ref text="For more about how to configure Verification, check out Verification configurations page"](/redirect/verification-configurations/)

---

*Last updated: 2026-02-03*