Loading demo…
1:N identity searchComing Soon
Face recognition API — 1:N search
Identify a person by searching one face against millions of enrolled identities. Returns ranked candidate matches with similarity scores, so you decide where the threshold sits rather than inheriting ours.
- 98.9% Top-1 accuracy
- ~140ms median latency
- Scales to millions of enrolled identities
- Ranked candidates with per-match scores
Availability
Face recognition is in private beta
1:N search needs a gallery to search, so there is no meaningful one-click demo — the interesting behaviour only appears at your scale, with your data. Early access pairs API keys with help sizing and tuning the index.
No public demo yet
We run early access as a design-partner programme — you get API keys and we get feedback from a real integration before general release.
How it works
How 1:N face search works
Recognition is comparison run at scale against a gallery you own. The mechanics are familiar; the statistics are not, and that is where most deployments get surprised.
- 1
Enroll your gallery
Each known identity is converted from a face image into an embedding and stored against your own identifier. This is a one-time cost per person, and the stored templates are what you search against.
- 2
Submit a probe face
A query image is detected, aligned, and embedded using the same model, so the probe lives in the same vector space as everything already enrolled.
- 3
The gallery is searched
The probe embedding is compared against the gallery using an indexed nearest-neighbour search, which keeps latency roughly flat as the gallery grows rather than scaling linearly with it.
- 4
Ranked candidates come back
You get an ordered list of candidate identities with similarity scores — not a verdict. Where you threshold that list is a policy decision that depends on what a wrong answer costs you.
Comparison
1:1 comparison vs 1:N recognition
Plenty of teams reach for recognition when comparison would do. Recognition is the heavier choice on every axis — capability, cost, and compliance — so it is worth being sure you need it.
| 1:1 comparison | 1:N recognition | |
|---|---|---|
| Question asked | Are these two faces the same person? | Who is this person, if anyone? |
| Input | Two face images | One probe image plus an enrolled gallery |
| Output | Score and match verdict | Ranked candidates with scores |
| State | Stateless — nothing is stored | Stateful — you hold biometric templates |
| Key metric | TAR at a fixed FAR | Rank-1 accuracy at your gallery size |
| Scaling risk | None — independent of user count | False matches accumulate with gallery size |
| Compliance load | Lower — no biometric database | Higher — Art. 9 data at rest |
If you already know who the user claims to be — which is true in almost every onboarding and login flow — you want 1:1 comparison, available today. Reach for recognition only when no identity is claimed.
Operations
What running a gallery actually costs
The API call is the easy part. Three operational realities decide whether a recognition deployment stays manageable.
You now hold biometric data
Embeddings are biometric data under GDPR Article 9 even though they are not images. Encryption at rest, access control, retention limits, and deletion-on-request all apply to the template store.
Model upgrades mean re-enrollment
Embeddings are not portable across model versions. Keep source images or accept that an upgrade invalidates the gallery — decide this before you have millions of templates, not after.
False matches scale with N
The same false accept rate produces a hundred times more false matches at 100,000 identities than at 1,000. Tune the threshold at your real gallery size, not on a benchmark set.
The compliance side of holding templates is covered in GDPR and biometric data; the enterprise architecture patterns are in face recognition for enterprise IAM.
Use cases
When you need 1:N
Duplicate account detection
Search every new applicant against your enrolled base to catch one person registering under multiple identities.
Watchlist screening
Check an incoming face against a known list, returning ranked candidates for a human to adjudicate rather than an automatic block.
Employee access control
Identify staff at a door or kiosk without requiring a badge tap or a claimed identity first.
Returning customer recognition
Recognise a known customer at a service point where asking them to identify themselves adds friction.
FAQ
Face recognition FAQ
- What is the difference between face recognition and face comparison?
- Face comparison is 1:1 — you supply two faces and ask whether they match. Face recognition is 1:N — you supply one face and ask which enrolled identity it belongs to, if any. Recognition runs a comparison against every gallery entry, so it inherits comparison accuracy but faces a harder statistical problem as the gallery grows.
- Why does accuracy change with gallery size?
- Every comparison carries a small chance of a false match. At a 0.01% false accept rate against a gallery of 1,000 people you expect roughly 0.1 false accepts per query; at 100,000 people that becomes about 10. A 1:1 accuracy figure therefore tells you very little about 1:N behaviour at your intended scale.
- What is Rank-1 accuracy?
- The probability that the correct identity appears as the top-ranked result for a query. It is the metric that matters for gallery search, and unlike 1:1 verification accuracy it degrades measurably as the gallery grows. Always ask for it at the gallery size you plan to run.
- What does the API return?
- A ranked list of candidate identities with a similarity score for each, rather than a single verdict. Returning candidates instead of an answer is deliberate: at scale, the right integration pattern is usually to threshold the top result and route near-misses to review rather than auto-accept.
- How are identities enrolled?
- Enrollment converts a face image into an embedding and stores it against your identifier. The stored embedding is biometric data in its own right under GDPR Article 9, so it must be encrypted at rest and access-controlled — enrolling is a materially different compliance posture from stateless 1:1 comparison.
- What happens when the model is updated?
- Embeddings from different model versions are not comparable. A model upgrade means re-enrolling the gallery from source images, which is why you should keep enrollment images or plan a migration path before you have millions of templates. This is the single most underestimated cost in running recognition at scale.
- Can it detect duplicate registrations?
- Yes — that is 1:N search pointed at your own user base. Searching each new applicant against enrolled identities catches one person registering under several names, which 1:1 comparison structurally cannot do.
- When will the API be available?
- Face recognition is in private beta with design partners. Gallery search has more deployment-specific tuning than the stateless APIs, so we are onboarding gradually with direct engineering support. Contact us to be considered.
Related reading
Go deeper
Understanding face recognition accuracy
TAR, FAR, Rank-1, and why 1:N accuracy has to be evaluated at your intended gallery size.
ReadFace recognition for enterprise IAM
Three-tier architecture, NIST AAL alignment, and the model update migration problem.
ReadAvailable today: face comparison, face detection, and face blur.
Ready to ship identity verification?
Talk to our engineering team about your use case. We'll get you up and running in under a day.
SOC 2 Type II · GDPR Ready · ISO 27001