Use Cases

Start from what you want to achieve. In VerifEye, every use case is expressed as a verification configuration — you enable the verifiers you need (each with a mode) and run the verification; the result tells you the outcome.

I want to…	Verification configuration	Details
Verify users are real people	Liveness (Verification)	Check the details
Check users' ages (e.g. 18+)	Age (ThresholdVerification, Above 18) + Liveness	Check the details
Prevent fake / duplicate accounts	Face Recognition (DuplicateVerification) + Liveness	Check the details
Authenticate returning users (replace SMS / email MFA)	Face Recognition (MatchVerification with reExternalId) + Liveness	Check the details
Register faces, then check them later	Face Recognition (UniqueMatchVerification / MatchVerification) + Liveness	Check the details
Get the full package	Liveness + Face Recognition + Age + Gender	Check the details

---

Confirm a user is a real, live person

Goal — onboarding, sign-up, or any flow where you need to know a real human (not a bot, a photo or a replay) is present.

Verification configuration — enable the Liveness verifier with Type Verification. The verification returns reLivenessResult (passed / failed).

Learn more:

---

Check a user's age (age assurance)

Goal — age-gated content, purchases or sign-ups where you need to confirm a user is above a threshold (for example 18+).

Verification configuration — enable the Age verifier with Type ThresholdVerification (Threshold 18, Direction Above), together with Liveness (Verification) so the face is real. The verification returns reAgeVerificationResult and the estimated reAge.

Learn more:

---

Prevent fake or duplicate accounts

Goal — enforce one-person-one-account, or block bonus / promo abuse and duplicate registrations.

Verification configuration — enable the Face Recognition verifier with Type DuplicateVerification, together with Liveness (Verification) so a photo cannot be registered. On each sign-up the verification stores the face if it is new and fails if the face is already in the collection (a duplicate). The result is returned in reFaceRecognitionResult.

Learn more:

---

Authenticate returning users

Goal — passwordless login, step-up authentication for sensitive actions, or account recovery — replace SMS / email MFA without sending codes.

Verification configuration — enable the Face Recognition verifier with Type MatchVerification and pass your own identifier as reExternalId, together with Liveness (Verification). The first call enrolls the user's face under reExternalId; subsequent calls perform a 1:1 match against that enrolled face. On return visits you can disable Liveness/Age/Gender for a lighter flow.

Learn more:

---

Register faces, then check them later

Goal — you already hold reference faces (for example onboarding photos) and want to pre-register them, then later decide whether a new subject is one of them.

Flow

1. Create a verification with the Face Recognition verifier enabled. The verification has an associated collection — you can see it in the Developer Console (and, later, via the API).
2. Register the faces into that collection — index your reference images into it. If you want to look a face up by your own identifier, attach an externalKey to it.
3. Run the verification to decide whether the subject is already in the collection. You can run it multiple times, and you can do a specific 1:1 check by supplying your identifier as reExternalId:
   • DuplicateVerification — fails if the face is already in the collection (is this a duplicate?).
   • UniqueMatchVerification — ensures the subject is uniquely represented by reExternalId.
   • MatchVerification — 1:1: confirms the subject matches the face stored under the given reExternalId. Enrolls the face automatically on the first visit for a new reExternalId.
   • MatchOnlyVerification — 1:1 like MatchVerification, but never enrolls: it passes only if a face is already registered under the given reExternalId, and fails (storing nothing) if none is. Use it for the verify-only side of an enroll-then-verify flow.

---

Pre-registering images via the Face Recognition API, then checking with MatchOnlyVerification

When you enroll the reference images yourself through the API (step 2 above) rather than letting a verification auto-enroll them on first sight, pair that registration with MatchOnlyVerification so subjects you never registered fail closed instead of being silently added:

1. Index Face — index each reference image into the verification's collection and keep the returned faceId.
2. Set External Key — associate your own identifier (for example user-123) with that faceId. See External Key Management for the full set of endpoints.
3. Run the verification with Face Recognition set to MatchOnlyVerification and pass the same identifier as reExternalId. The check passes only when the subject matches the face you pre-registered under that identifier, and fails for anyone not registered — the verification itself never stores a face.

This differs from MatchVerification, where the first visit for a new reExternalId would enroll the presented face automatically. With MatchOnlyVerification, the API registration is the only way a face enters the collection, so you stay in full control of who can pass.

Typical scenarios: live image registration followed by a static image match, or profile-picture validation against the face registered for that customer.

Learn more:

---

Get the full package

Goal — a complete identity check in one flow: confirm a real, unique person, estimate their age and authenticate them.

Verification configuration — enable several verifiers on a single verification: Liveness (Verification), Face Recognition (UniqueMatchVerification or DuplicateVerification), Age (ThresholdVerification) and Gender (CalculationOnly). The user completes one guided flow and you receive every outcome together.

Learn more:

---

Last updated: 2026-07-08