Concept

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.

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.

---

Last updated: 2026-02-03