Face Detection
Locate human faces in an image or camera frame and return their position as bounding boxes.
Tatvora Face AI
Four face intelligence APIs, not one face model
Face detection, recognition, verification and liveness solve different problems and are published as separate AI models with separate endpoints. That separation is deliberate: you pay only for the step you need, and each result means exactly one thing.
The four models
What each API answers
Face Recognition
Match a captured face against the identity set your application supplies to determine who the person is.
Face Verification
Compare a reference image against a live capture and receive a match or no-match decision with a similarity score.
Face Liveness
Determine whether a captured face belongs to a physically present person rather than a printed photo or replayed screen.
Workflow
Chaining the models into an authentication decision
Customers can call these APIs individually or combine them. A full authentication flow typically runs detection first as a cheap gate, then identity, then liveness.
- Camera / Image
- Face Detection Is a face present, and where?
- Recognition or Verification Who is it, or is it who they claim?
- Liveness Validation Is the person physically present?
- Authentication Result
Worked example
Face attendance, gate by gate
Every gate answers a different question and can reject on its own. This is why Tatvora ships four independent face models instead of one combined check.
Attendance authentication — four models in sequence
Employee opens the attendance app
Camera opens
Is a face present?
Find a face and its position in the frame
Face Detection AI
YES
NO No face — reject
Is the person really there?
Rule out a printed photo or a screen replay
Face Liveness AI
LIVE
SPOOF Spoof — reject
Is this the authorised employee?
Match against the stored reference photo, or identify from your roster
Face Verification AI
or Face Recognition AI
MATCH
NO MATCH Not authorised — reject
Attendance approved
Punch in / punch out recorded
Why four models, not one
Each gate answers a different question and can reject on its own. Detection without liveness accepts a photograph. Liveness without verification lets any live person clock in. Combining them is what makes the check hold.
Use them separately too
Every model is an independent API. Call one, or chain them as above — your workflow decides. One quota covers all six.
Illustrative workflow. The order of gates, the thresholds and the rejection handling are yours to design; Tatvora supplies each model as a separate call.
Choosing a model
Which API answers your question?
Most integration mistakes come from picking the wrong one. This table is the shortest way to get it right.
| Model | Question it answers | Input | Output | Endpoint |
|---|---|---|---|---|
| Face Detection | Is there a face, and where is it? | One image | Face count and bounding boxes | /api/v1/face/detect |
| Face Recognition | Who is this person? | One image + your registered identities | Matched identity and similarity | /api/v1/face/recognize |
| Face Verification | Are these two faces the same person? | Two images | Match decision and similarity | /api/v1/face/verify |
| Face Liveness | Is this a live person or a spoof? | One capture | is_live, spoof_detected |
/api/v1/face/liveness |
Detection is not recognition
Face Detection carries no identity information — it reports that a face exists and
where. Recognition searches your registered identities; verification compares two
specific images. Liveness answers none of those questions, only whether the subject
is physically present.
Industries
Where Face AI is deployed
FAQ
Face AI questions
Face Detection answers "is there a face here, and where?" and returns bounding boxes. Face Recognition answers "who is this?" by comparing a captured face against the candidate identity set your application sends with the request. Detection carries no identity information.
Face Verification is one-to-one matching. You supply two images — typically a reference photograph and a live capture — and the API returns whether they are the same person, with a similarity score you can threshold. It compares only those two images; to search a candidate set, use Face Recognition.
Face Liveness determines whether the person in front of the camera is physically present at capture time, rather than a printed photo or a screen replay. It is usually combined with verification or recognition to turn a face check into an authentication control.
Detecting presentation attacks — printed photographs, screen and video replays, and similar spoofing attempts — is what the model is built for. It meaningfully raises the cost of an attack, but no liveness model is absolute, so treat it as one control in a wider security design. We do not publish accuracy figures; request current performance characteristics for your capture conditions during evaluation.
Yes, including multi-page PDFs. Extracted text is returned with page attribution so you can map content back to its source page.
Yes. Scanned pages, photographed documents and images are all supported, alongside digital PDFs and DOCX files. Capture quality still affects results, so we recommend running representative samples through an evaluation key before you commit to a plan.
Build a face workflow that holds up
Start with detection, add verification or recognition, and gate the decision with liveness. Each API is independent, so you only pay for the steps you use.