Challenges
Configure and customize active liveness challenges.
Active mode asks the user to complete a small number of challenges — a randomised subset of the list below. Randomisation across sessions is what makes the flow hard to replay: a recorded video of a previous session will not satisfy a fresh sequence of prompts.
Challenge types
| Challenge | Prompt the user sees | What it verifies |
|---|---|---|
blink | "Blink your eyes" | Eyelid motion with the right intensity curve. |
turn_left | "Turn your head left" | Yaw rotation past a threshold, then return. |
turn_right | "Turn your head right" | Yaw rotation in the opposite direction. |
nod | "Nod your head" | Pitch oscillation — chin down and back up. |
smile | "Smile" | Mouth-corner displacement consistent with a genuine smile. |
mouth_open | "Open your mouth" | Vertical mouth opening crossing a threshold. |
eyebrow_raise | "Raise your eyebrows" | Brow lift against the upper face. |
eye_follow | "Follow the dot" | Gaze tracks a moving on-screen target. |
Platform parity: eye_follow is supported on Android and Flutter. On iOS
the drop-in UI does not yet render the moving-dot overlay, so eye_follow is
excluded from the default iOS challenge pool. The ChallengeType.eyeFollow
enum case is still available — callers supplying a custom UI can opt in by
passing it explicitly in ILiveConfig.challengeTypes, in which case the SDK
logs a warning. Full parity will ship once the iOS overlay lands.
Every session picks a short, randomised sequence from this set. The exact count and ordering is chosen per session; you don't configure it per request.
When the challenge check fails
A missed or unconvincing challenge does not necessarily produce a fail
verdict. The platform weighs challenge performance against the
anti-spoof, deepfake, and motion signals and picks the appropriate
verdict — usually retry when the only issue is a muddy challenge
attempt.
Related: Active vs passive · Liveness overview.