> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# बायोमेट्रिक प्रमाणीकरण API: पासवर्ड-रहित KYC

> Didit से लौटने वाले उपयोगकर्ताओं को लाइवनेस और चेहरा मिलान से प्रमाणित करें। बिना दस्तावेज़, 2 सेकंड से कम में पासवर्ड-रहित सत्यापन। $0.10 प्रति कॉल।

Didit का बायोमेट्रिक प्रमाणीकरण समाधान लौटने वाले उपयोगकर्ताओं के लिए एक सुव्यवस्थित सत्यापन अनुभव प्रदान करता है। इस वर्कफ़्लो को केवल उपस्थिति सत्यापन के लिए सिर्फ़ लाइवनेस जाँच करने के लिए कॉन्फ़िगर किया जा सकता है, या संग्रहीत पोर्ट्रेट के साथ अधिक मजबूत पहचान पुष्टि के लिए लाइवनेस को चेहरे की पहचान (फ़ेशियल रिकग्निशन) के साथ जोड़ा जा सकता है। यह लचीलापन उच्च सुरक्षा मानकों को बनाए रखते हुए एक घर्षण-रहित अनुभव तैयार करता है।

बायोमेट्रिक प्रमाणीकरण इंटीग्रेशन प्रॉम्प्ट
        प्रॉम्प्ट को क्लिपबोर्ड पर कॉपी करें



      
      

\<pre>

\````# Goal
Integrate Didit Biometric Authentication (passwordless re-verification of returning users) into your app.

\# Delivery mode
Biometric Authentication is **session-only**. There is no dedicated /v3/biometric-auth/ endpoint. It is delivered through a session whose workflow is configured for biometric-auth use (workflow_type=BIOMETRIC_AUTHENTICATION). Under the hood it reuses the same LivenessV3 + FaceMatchV3 serializers as the regular KYC flow — the only difference is the reference image source.

\# Reference image resolution (create time)
The reference face the live selfie is matched against comes from one of two places:
\- `portrait_image` (Base64, max 2MB) sent in the create-session request: always wins when provided.
\- Omitted `portrait_image`: Didit reuses a face already stored for the `vendor_data` user, resolved in this order: (1) face captured during an approved liveness check, (2) ePassport chip photo from an approved ID verification, (3) portrait cropped from the ID document of an approved ID verification, (4) a manually enrolled profile face (Users API / Console upload).
\- If `portrait_image` is omitted and the user has NO stored face, session creation fails with 400: {"portrait_image": "No stored face image was found for this user. Send a portrait_image, or complete an approved verification with face liveness or an ID document for this vendor_data first."}
\- If `portrait_image` is omitted and `vendor_data` is missing too, session creation fails with 400: {"portrait_image": "A portrait image is required to perform face match for this workflow. Send a portrait_image, or provide the vendor_data of a user with a previously stored face image to reuse it."}

\# Steps
1\. Create a Biometric Auth workflow in the Business Console (workflow_type=BIOMETRIC_AUTHENTICATION). Configure the LIVENESS method (PASSIVE / ACTIVE_3D / FLASHING) and the FACE_MATCH similarity threshold.
2\. The returning user must already have a face on file under the same `vendor_data` (approved verification with liveness or ID document, or an enrolled profile face); otherwise send `portrait_image` explicitly.
3\. Create a session — POST /v3/session/ with { workflow_id, vendor_data, callback }. Use the **same vendor_data** as the user's prior verification so the stored face can be retrieved. Add `portrait_image` only to override the stored face.
4\. Open session.url for the user (or mount the Web/Mobile SDK).
5\. Fetch the decision — GET /v3/session/{sessionId}/decision/ or subscribe to session.status.updated.

curl example:
\```bash
curl -X POST 'https://verification.didit.me/v3/session/' \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"workflow_id": "YOUR_BIOMETRIC_AUTH_WORKFLOW_ID",
"vendor_data": "user-1234",
"callback": "https://yourapp.com/post-reauth"
}'
\```

\# Decision surface
Biometric Authentication surfaces results across **two arrays** on the decision payload — there is no biometric_auths[] array:
\- `liveness_checks[]` — the live capture (status + score + warnings under LogWarningChoices.LIVENESS).
\- `face_matches[]` — the comparison against the stored portrait (status + score + warnings under LogWarningChoices.FACEMATCH).

Approve the user only when **both** entries are status="Approved".

\# Status enum (per liveness_checks[].status and face_matches[].status)
"Not Started" | "In Progress" | "Approved" | "In Review" | "Declined" | "Abandoned" | "Kyc Expired"

\# Warnings
\- Liveness side (LogWarningChoices.LIVENESS): LOW_LIVENESS_SCORE, LIVENESS_FACE_ATTACK, NO_FACE_DETECTED, MULTIPLE_FACES_DETECTED, FACE_IN_BLOCKLIST, DUPLICATED_FACE.
\- Face Match side (LogWarningChoices.FACEMATCH): LOW_FACE_MATCH_SIMILARITY, NO_REFERENCE_IMAGE.
Full catalogue: /core-technology/biometric-auth/warnings-biometric-authentication.

\# Failure modes to handle
\- 400 on session creation with the "No stored face image was found for this user" message: the user has no stored face under this vendor_data; route them to first-time KYC, or send portrait_image explicitly.
\- NO_REFERENCE_IMAGE on face_matches[] — the reference image could not be resolved at match time; route the user to first-time KYC instead.
\- LOW_FACE_MATCH_SIMILARITY — the live selfie does not match the stored portrait; do not authenticate.
\- LIVENESS_FACE_ATTACK — presentation attack detected; reject and flag the account.
\- FACE_IN_BLOCKLIST — user has been added to your blocklist since enrolment; block.

\# See also
\- Canonical schema: /reference/data-models#biometric-authentication (and /reference/data-models#liveness-check, /reference/data-models#face-match)
\- Per-feature report: /core-technology/biometric-auth/report-biometric-authentication
\- Risk catalogue: /core-technology/biometric-auth/warnings-biometric-authentication
\- Full integration playbook: /integration/integration-prompt````

\</pre>



      
      

यहाँ पेस्ट करें

## मुख्य विशेषताएँ#### तेज़ पुनः सत्यापन- किसी दस्तावेज़ स्कैनिंग की आवश्यकता नहीं
- सेकंडों में सत्यापन पूरा होता है
- उपयोगकर्ता घर्षण और ड्रॉप-ऑफ़ को कम करता है#### उन्नत सुरक्षा- चेहरा मिलान 1:1 के समान न्यूरल नेटवर्क आर्किटेक्चर का उपयोग करता है
- अकाउंट टेकओवर के प्रयासों को रोकता है
- स्पूफिंग को रोकने के लिए लाइवनेस डिटेक्शन शामिल है#### इंटीग्रेशन में लचीलापन- वेब-आधारित रूप में उपलब्ध
- कॉन्फ़िगर करने योग्य मिलान थ्रेशोल्ड
- बेहतर सुरक्षा के लिए वैकल्पिक डिवाइस और IP विश्लेषण## यह कैसे काम करता है**1. सत्र निर्माण**जब आप **चेहरा मिलान** वाले वर्कफ़्लो के लिए बायोमेट्रिक प्रमाणीकरण सत्र बनाते हैं, तो Didit को लाइव सेल्फ़ी से तुलना करने के लिए एक संदर्भ चेहरे (रेफ़रेंस फ़ेस) की आवश्यकता होती है।
आपके पास दो विकल्प हैं:- अपने स्वयं के डेटाबेस से Base64 (अधिकतम 2MB) में **`portrait_image` भेजें**। प्रदान किए जाने पर इसे हमेशा प्राथमिकता दी जाती है।
- **`portrait_image` छोड़ दें** और उपयोगकर्ता का `vendor_data` पास करें। Didit उस उपयोगकर्ता के लिए पहले से संग्रहीत चेहरे का स्वचालित रूप से पुनः उपयोग करता है, जिसका चयन इस क्रम में किया जाता है:
  1. एक **स्वीकृत लाइवनेस जाँच** के दौरान कैप्चर किया गया चेहरा
  2. किसी स्वीकृत पहचान सत्यापन से **ePassport चिप फ़ोटो**
  3. किसी स्वीकृत पहचान सत्यापन के **पहचान दस्तावेज़ से क्रॉप किया गया पोर्ट्रेट**
  4. **मैन्युअल रूप से नामांकित प्रोफ़ाइल चेहरा** (Users API या कंसोल अपलोड)```json theme={null}
{
  "workflow_id": "11111111-2222-3333-4444-555555555555",
  "vendor_data": "user-123",
  "callback": "https://example.com/verification/callback",
  "metadata": { "login_attempt": "2" }
}
```> [!WARNING]
>
> केवल **स्वीकृत** सत्रों के चेहरों (या आपके द्वारा स्वयं नामांकित चेहरों) का ही पुनः उपयोग किया जाता है। यदि आप `portrait_image` छोड़ देते हैं और उपयोगकर्ता का कोई संग्रहीत चेहरा नहीं है, तो सत्र निर्माण `400` और इस संदेश के साथ विफल हो जाता है: `No stored face image was found for this user. Send a portrait_image, or complete an approved verification with face liveness or an ID document for this vendor_data first.` यदि आप `vendor_data` भी छोड़ देते हैं, तो `400` संदेश आपसे संग्रहीत चेहरे के साथ `portrait_image` या `vendor_data` भेजने के लिए कहता है।**2. लाइव फ़ोटो कैप्चर**प्रमाणीकरण प्रक्रिया के दौरान:| जाँच | विवरण |
| - | - |
| **लाइवनेस सत्यापन** | Passive Liveness या 3D Action & Flash का उपयोग करके स्पूफिंग को रोकता है |
| **छवि की गुणवत्ता** | सिस्टम प्रकाश, पोज़िशनिंग और स्पष्टता का मूल्यांकन करता है |
| **पुनः प्रयास मार्गदर्शन** | ख़राब गुणवत्ता वाली छवियों को सुधार के निर्देशों के साथ अस्वीकार कर दिया जाता है |
| **रियल-टाइम फ़ीडबैक** | उपयोगकर्ता को इष्टतम कैप्चर के लिए पोज़िशनिंग गाइड दिखाई देते हैं |**3. सत्यापन और परिणाम प्रोसेसिंग**सिस्टम आपके वर्कफ़्लो कॉन्फ़िगरेशन के आधार पर सत्यापन को संसाधित करता है:> [accordion] केवल लाइवनेस मोड
>
> यदि वर्कफ़्लो में **चेहरा मिलान अक्षम है**, तो सिस्टम केवल उपयोगकर्ता की लाइवनेस की पुष्टि करता है; किसी संदर्भ चेहरे की आवश्यकता नहीं होती है और `portrait_image` की आवश्यकता नहीं होती है। एक सफल जाँच का परिणाम **स्वीकृत** प्रमाणीकरण होता है, जो सामान्य उपस्थिति सत्यापन के लिए उपयोगी है।> [accordion] लाइवनेस + चेहरा मिलान मोड
>
> यदि वर्कफ़्लो में **चेहरा मिलान सक्षम है** (`portrait_image` से संदर्भ चेहरा या उपयोगकर्ता का संग्रहीत चेहरा):
>
> 1. सिस्टम पहले **लाइवनेस जाँच** करता है
> 2. यदि लाइवनेस पास हो जाती है, तो नई सेल्फ़ी की संदर्भ चेहरे से तुलना की जाती है
> 3. एक **समानता स्कोर (0–100%)** जनरेट होता है
> 4. स्कोर आपके कॉन्फ़िगर किए गए थ्रेशोल्ड से ऊपर है → **स्वीकृत**
> 5. स्कोर थ्रेशोल्ड से नीचे है → **अस्वीकृत**परिणाम **API रिस्पॉन्स**, **Business Console**, और **webhook** के माध्यम से उपलब्ध होते हैं।


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.