मुख्य सामग्री पर जाएं

अवलोकन

लाइवनेस रिपोर्ट Didit द्वारा यह सत्यापित करते समय देखी गई हर चीज़ को कैप्चर करती है कि कैमरे के सामने एक वास्तविक, जीवित व्यक्ति मौजूद था — कोई प्रिंट किया हुआ फ़ोटो, स्क्रीन रीप्ले, या डीपफ़ेक नहीं। इसमें लाइवनेस विधि, 0–100 विश्वास स्कोर, संदर्भ सेल्फ़ी और कैप्चर वीडियो, एक वैकल्पिक आयु अनुमान, पैसिव-लाइवनेस गुणवत्ता मेट्रिक्स, और आपके एप्लिकेशन के इतिहास और ब्लॉकलिस्ट के विरुद्ध क्रॉस-सत्र चेहरा मिलान शामिल हैं। यह रिपोर्ट तब तैयार की जाती है जब उपयोगकर्ता वर्कफ़्लो में लाइवनेस चरण पूरा कर लेता है (या स्टैंडअलोन फ़ेस endpoint पर कॉल करता है)। Didit तीन लाइवनेस विधियों (सक्रिय 3D, फ़्लैशिंग, या पैसिव) में से एक चलाता है, कैप्चर को स्कोर करता है, ज्ञात स्पूफिंग पैटर्न की जाँच करता है, और आपके एप्लिकेशन में देखे गए प्रत्येक अन्य चेहरे के साथ चेहरे की बायोमेट्रिक तुलना करता है। प्रत्येक रिपोर्ट का अपना status होता है — जो समग्र सत्र स्थिति से स्वतंत्र होता है — और यह दर्शाता है कि केवल लाइवनेस चरण का समाधान कैसे हुआ:
  • स्वीकृत — चेहरा डिटेक्ट हुआ, लाइवनेस स्कोर समीक्षा थ्रेशोल्ड से ऊपर है, कोई ऑटो-डिक्लाइन चेतावनी ट्रिगर नहीं हुई।
  • समीक्षाधीन — समीक्षा के लिए रूट की गई एक या अधिक चेतावनियाँ ट्रिगर हुईं, या स्कोर समीक्षा थ्रेशोल्ड पर या उससे कम है लेकिन अस्वीकार थ्रेशोल्ड से ऊपर है।
  • अस्वीकृत — एक ऑटो-डिक्लाइन स्थिति ट्रिगर हुई (NO_FACE_DETECTED, LIVENESS_FACE_ATTACK, FACE_IN_BLOCKLIST, या आयु-अनुमान प्रवाह पर आयु जोखिम), एक कॉन्फ़िगर करने योग्य चेतावनी को अस्वीकृति के लिए रूट किया गया था, या स्कोर अस्वीकार थ्रेशोल्ड पर या उससे नीचे है।
  • पूरा नहीं हुआ — उपयोगकर्ता ने लाइवनेस चरण कभी पूरा नहीं किया।

API रिस्पॉन्स में यह कहाँ दिखाई देता है

लाइवनेस रिपोर्ट GET /v3/session/{sessionId}/decision/ में liveness_checks[] के रूप में दिखाई देती है — हमेशा एक JSON ऐरे, कभी भी एकवचन liveness ऑब्जेक्ट नहीं। एकाधिक प्रविष्टियाँ तब दिखाई देती हैं जब कोई वर्कफ़्लो लाइवनेस को एक से अधिक बार चलाता है (उदाहरण के लिए प्राथमिक जाँच के साथ एक पुनः कैप्चर)।
response.liveness_checks[0] पढ़ें और ऐरे की प्रत्येक प्रविष्टि पर काम करें — एकवचन liveness संरचना जिसका उल्लेख कुछ पुराने ट्यूटोरियल में किया गया था, v3 निर्णय endpoint पर मौजूद नहीं है।

Schema

कैनोनिकल फ़ील्ड-दर-फ़ील्ड स्कीमा Data models संदर्भ पृष्ठ पर उपलब्ध है। नीचे दिए गए फ़ील्ड उस कैनोनिकल स्कीमा को दर्शाते हैं।

क्रॉस-सत्र चेहरा मिलान

matches[] आपके एप्लिकेशन के इतिहास में उन चेहरों को सूचीबद्ध करता है जो इस सेल्फ़ी के विरुद्ध बायोमेट्रिक समानता थ्रेशोल्ड को पार कर गए — अधिकतम 5 प्रविष्टियाँ, पहले ब्लॉकलिस्ट और अनुमति-सूची वाले चेहरे, फिर अवरोही समानता क्रम में। पात्र उम्मीदवार ब्लॉकलिस्ट किए गए चेहरे, अनुमति-सूची वाले चेहरे, Approved सत्रों के चेहरे, और आपके वेंडर उपयोगकर्ताओं के विरुद्ध इंपोर्ट किए गए चेहरे हैं। एक ही उपयोगकर्ता से संबंधित चेहरे (समान vendor_data, या उपलब्ध होने पर समान वेंडर-उपयोगकर्ता) को पूरी खोज से बाहर रखा जाता है — डुप्लिकेट डिटेक्शन और ब्लॉकलिस्ट स्क्रीनिंग दोनों से। प्रत्येक प्रविष्टि में शामिल हैं:

स्थिति मान

स्थितियाँ साझा सुविधा-स्थिति enum (FeatureStatusChoices) से आती हैं।

उदाहरण

Approved — स्वच्छ सक्रिय-3D कैप्चर

In Review — पैसिव लाइवनेस, कम गुणवत्ता वाला कैप्चर और संभावित डुप्लिकेट

यहाँ चेहरे की गुणवत्ता (12.4) डिफ़ॉल्ट समीक्षा थ्रेशोल्ड (15) से नीचे है, ल्यूमिनेन्स (18.7) डिफ़ॉल्ट न्यूनतम (20) से नीचे है, और वर्कफ़्लो की डुप्लिकेट-चेहरा कार्रवाई समीक्षा पर सेट है — इसलिए तीनों चेतावनियों में log_type: "warning" है और रिपोर्ट की स्थिति In Review हो जाती है।

सुरक्षा नोट

लाइवनेस वीडियो और सेल्फ़ी बायोमेट्रिक डेटा हैं — हस्ताक्षरित URL अस्थायी होते हैं और समाप्त हो जाते हैं (डिफ़ॉल्ट रूप से 4 घंटे बाद)। इन्हें अल्पकालिक समझें: इन्हें कैश न करें या सार्वजनिक रूप से प्रदर्शित न करें। आमतौर पर आपके एप्लिकेशन को केवल status, score, और चेतावनियों की आवश्यकता होती है — अपने सर्वर पर बायोमेट्रिक डेटा को न्यूनतम रखने के लिए यथासंभव कम जानकारी स्टोर करें।

संबंधित

अंतिम संशोधन 7 नवंबर 2026