Derive a stable person_id from a selfie — identity is the output of the call, not the input. No identifier is declared by the user.
What this use case solves
Face Identification targets scenarios where no government-issued document relationship exists — situations where clients want to avoid collecting document numbers for privacy reasons.
Its core function is to create a unique identity for each face from a single selfie submission.
This enables you to:
- Detect returning users and prevent duplicate accounts — recognize whether the same person is returning or attempting to create multiple accounts, ensuring consistent identity recognition without official documents.
- Integrate via Web, Native, or API — using only the selfie image as input, with no additional document data required.
- Combine with other signals — layer IdFace alongside other capabilities as needed.
Use this use case when:
- You want a fully frictionless onboarding entry point, with no typing and no document upload.
- You need to recognize a returning user from their face alone, linking them back to an existing record on your side keyed by
person_id. - Your scenario requires identifying a user without prior context, such as kiosks, terminals, or first-touch B2B partner flows.
If your scenario already has a declared identifier and you only need to confirm the face belongs to that user, use Non-document onboarding instead.
Capabilities involved
Pipeline executed within a single process:
| Capability | Required | Role in the flow |
|---|---|---|
| Liveness | Recommended in all cases | Confirms that a real person is in front of the camera at the time of capture. Biometric anchor of the process. |
| IdFace | Required in all cases | Identifies the person from the selfie against the enrollment base and returns a stable opaque person_id. |
Risk Fraud Classification can be appended to the base pipeline when additional fraud signals are needed.
Prerequisites
- Bearer token — see Authentication.
- Sandbox credentials — see Environments.
- SDK or Web component installed — only for Web and SDK integrations.
Step-by-step implementation
- Native
- Web
- API
Integration via native SDK — capture runs inside your app using the Unico SDK for Android, iOS or Flutter.
- Install the SDK — add the Unico SDK dependency for your platform. See the setup guide for Android, iOS or Flutter.
- Create a process — call Create Process with
flow=idface. Use the returnedtokento initialize the SDK. - Start the capture — the SDK renders the camera UI and performs liveness detection on-device, returning the captured payload.
- Query the result — call Get Process to retrieve the IdFace results.
- Apply business rules — evaluate
idFace.resultfields to approve, deny or escalate.
Integration via iFrame, Redirect or Native — Unico hosts the capture UI, and you receive the result via polling.
- Create a process — call Create Process with
flow=idface. The response includes auserRedirectUrl. - Redirect the user — send the user to
userRedirectUrl. Unico renders the capture journey. OrwebAppTokenin native apps. - User completes the journey — after capture, the user is redirected back to your
callbackUri. - Query the result — call Get Process to retrieve the IdFace results.
- Apply business rules — evaluate
idFace.resultfields to approve, deny or escalate.
Direct API integration — capture the selfie using the Unico SDK or your own UI following the Capture Standard, then send the image directly to the Unico API.
- Capture the selfie — use the Unico SDK for your platform, or build your own UI following the Capture Standard, to obtain a selfie image that meets liveness requirements.
- Create a process — call Create Process with
flow=idface, the selfie asimagebase64. - Query the result — call Get Process to retrieve the IdFace results.
- Apply business rules — evaluate
idFace.resultfields to approve, deny or escalate.
