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

अवलोकन

हर सुविधा-वार रिपोर्ट service-didit-verification में परिभाषित V3 सीरियलाइज़र संरचना का पालन करती है। यही ऑब्जेक्ट तीन जगहों पर दिखता है, इसलिए यहाँ दिखने वाला स्कीमा इन सभी के लिए एकमात्र स्रोत है:
  • GET /v3/session/{sessionId}/decision/: हर सुविधा एक बहुवचन ऐरे के रूप में लौटाई जाती है (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], poa_verifications[], phone_verifications[], email_verifications[], aml_screenings[], ip_analyses[], database_validations[], questionnaire_responses[], signatures[], bank_verifications[] (देखें बैंक सत्यापन विधियाँ), और KYB के समकक्ष registry_checks[], document_verifications[], key_people_checks[])।
  • Webhook payloads (status.updated, data.updated): decision एनवेलप के भीतर वही संरचना।
  • स्टैंडअलोन API: एकल-ऑब्जेक्ट रिस्पॉन्स (चेहरा खोज, आयु अनुमान, बायोमेट्रिक प्रमाणीकरण) वही फ़ील्ड सेट इस्तेमाल करते हैं।
V3 ने मल्टी-इंस्टेंस वर्कफ़्लो पेश किए: हर सुविधा ऑब्जेक्ट में एक node_id होता है जो रिपोर्ट को उस वर्कफ़्लो ग्राफ़ नोड से जोड़ता है जिसने उसे बनाया। V2 एंडपॉइंट (एकवचन kyc, face, aml, आदि) बैकवर्ड-कम्पैटिबल बने रहते हैं, लेकिन केवल पहला इंस्टेंस लौटाते हैं।

सामान्य फ़ील्ड

हर रिपोर्ट ऑब्जेक्ट में ये फ़ील्ड होते हैं: मीडिया फ़ील्ड (portrait_image, front_image, document_file, …) सीमित वैधता अवधि वाले प्रीसाइंड URL हैं। URL को सहेजकर न रखें; उन्हें तुरंत डाउनलोड करें। उदाहरणों में इन्हें https://<media-host>/... के रूप में दिखाया गया है।

चेतावनी ऑब्जेक्ट

हर warnings[] ऐरे में यह लौटाया जाता है। स्कीमा logs/serializers/log.py:8-65 (LogV3Serializer) से है।

रिपोर्ट ऑब्जेक्ट

बाकी सेक्शन हर सुविधा-विशिष्ट रिपोर्ट ऑब्जेक्ट को कवर करते हैं। H3 हेडिंग का टेक्स्ट जानबूझकर स्थिर रखा गया है, ताकि अन्य दस्तावेज़ उसे सीधे लिंक कर सकें।

पहचान सत्यापन

यह हर उस KYC/ID दस्तावेज़ के लिए लौटाया जाता है जो उपयोगकर्ता जमा करता है। यह GET /v3/session/{sessionId}/decision/ में id_verifications[] के रूप में दिखता है, और V2 रिस्पॉन्स में kyc फ़ील्ड के भीतर। स्रोत: kyc/serializers/kyc.py:383-414 (IDVerificationV3Serializer, जो kyc/serializers/kyc.py:320-380 पर IDVerificationV2Serializer को विस्तारित करता है)।
वही ऑब्जेक्ट गैर-दस्तावेज़ विधि के साथ। केवल विधि-विशिष्ट कुंजियाँ बदलती हैं: जो कुछ दस्तावेज़ पढ़ने से भरा जाता है, वह अब रजिस्टर रिकॉर्ड या वॉलेट एट्रिब्यूट्स से भरा जाता है, और जो कुंजियाँ लागू नहीं होतीं वे null होती हैं।

NFC सत्यापन

ID दस्तावेज़ की प्रत्येक चिप रीड के लिए लौटाया जाता है: ICAO 9303 ePassport या eID चिप, या Japan My Number Card का JPKI के माध्यम से पढ़ना (chip_protocol: "jpki")। यह GET /v3/session/{sessionId}/decision/ में nfc_verifications[] के रूप में आता है (हर पैरेंट KYC रिकॉर्ड के लिए एक)। स्रोत: kyc/serializers/epassport.py:121-139 (NFCV3Serializer, जो kyc/serializers/epassport.py:83-118 पर NFCV2Serializer को विस्तारित करता है)।

लाइवनेस जाँच

प्रति लाइवनेस सत्र लौटाया जाता है। GET /v3/session/{sessionId}/decision/ में liveness_checks[] के रूप में दिखता है। स्रोत: face/serializers/face.py:301-320 (LivenessV3Serializer, जो face/serializers/face.py:216-298 पर LivenessV2Serializer को विस्तारित करता है)।
पैसिव सत्र यह फ़ील्ड तब लौटाता है जब उसकी कैप्चर में रिकॉर्डिंग सहेजी गई हो, और जब सत्र ने कोई रिकॉर्डिंग नहीं रखी हो तो null। ऊपर का उदाहरण ऐसे ही सत्र का है जिसने कोई रिकॉर्डिंग नहीं रखी।

चेहरा मिलान

प्रति चेहरा-मिलान तुलना के लिए लौटाया जाता है (आमतौर पर उपयोगकर्ता का लाइवनेस चेहरा दस्तावेज़ के पोर्ट्रेट से)। GET /v3/session/{sessionId}/decision/ में face_matches[] के रूप में दिखता है। स्रोत: face/serializers/face.py:367-389 (FaceMatchV3Serializer, जो face/serializers/face.py:323-364 पर FaceMatchV2Serializer को विस्तारित करता है)।

चेहरा खोज

यह स्टैंडअलोन Face Search API (POST /v3/face-search/) से लौटाया जाता है। Face Search कभी भी /v3/session/{sessionId}/decision/ में बहुवचन array के रूप में नहीं आता। जब save_api_request=true के साथ इसे सहेजा जाता है, तो सत्र वहाँ features[] में FACE_SEARCH प्रविष्टि के रूप में और liveness_checks[] में एक आइटम के रूप में दिखता है, जिसमें सहेजे गए matches होते हैं। स्रोत: apis/serializers/face_search.py:8-79 (FaceSearchResponseSerializer, जो FaceSearchDetailsSerializer को समाहित करता है); मिलान dict face/utils/utils.py:869-884 में बनाए जाते हैं। शीर्ष स्तर का रिस्पॉन्स: face_search object:

चेहरा खोज मिलान ऑब्जेक्ट

AML स्क्रीनिंग

स्क्रीनिंग की गई हर इकाई के लिए लौटाया जाता है। KYC और KYB, दोनों सत्रों के लिए GET /v3/session/{sessionId}/decision/ में aml_screenings[] के रूप में दिखता है। स्रोत: aml/serializers/aml.py:63-85 (AMLV3Serializer, जो aml/serializers/aml.py:28-60 के AMLV2Serializer को विस्तारित करता है)।

IP विश्लेषण

हर कैप्चर किए गए नेटवर्क स्थान के लिए लौटाया जाता है। KYC और KYB, दोनों सत्रों के लिए GET /v3/session/{sessionId}/decision/ में ip_analyses[] के रूप में दिखता है। स्रोत: kyc/serializers/location.py:196-243 (IPAnalysisSerializerV3)।

स्थान सत्यापन

हर स्थान सत्यापन चरण के लिए लौटाया जाता है। GET /v3/session/{sessionId}/decision/ में geolocation_checks[] के रूप में दिखता है: हर चरण का एक आइटम, यानी उसका स्वीकृत प्रयास। geolocation_attempts[] हर चरण के हर प्रयास को सबसे पुराने प्रयास से शुरू करके सूचीबद्ध करता है। जिस वर्कफ़्लो में यह चरण नहीं है, उसमें दोनों null होते हैं। स्रोत: GeolocationDecisionSerializer। हर फ़ील्ड और उदाहरण लोकेशन सत्यापन रिपोर्ट में हैं।

पते का प्रमाण

हर प्रस्तुत पता दस्तावेज़ के लिए लौटाया जाता है। यह GET /v3/session/{sessionId}/decision/ में poa_verifications[] के रूप में दिखता है। स्रोत: poa/serializers/poa.py:212-227 (POAV3Serializer, जो poa/serializers/poa.py:173-209 के POAV2Serializer को विस्तारित करता है)।

फ़ोन सत्यापन

हर फ़ोन-सत्यापन प्रयास के लिए लौटाया जाता है। KYC और KYB, दोनों सत्रों के लिए GET /v3/session/{sessionId}/decision/ में phone_verifications[] के रूप में दिखता है। स्रोत: phone/serializers/phone.py:251-266 (PhoneV3Serializer, जो phone/serializers/phone.py:103-248 पर PhoneV2Serializer का विस्तार है)।

ईमेल सत्यापन

हर ईमेल-सत्यापन प्रयास के लिए लौटाया जाता है। KYC और KYB, दोनों सत्रों के लिए GET /v3/session/{sessionId}/decision/ में email_verifications[] के रूप में दिखता है। स्रोत: email_verification/serializers/email.py:149-164 (EmailV3Serializer, जो email_verification/serializers/email.py:38-146 पर EmailV2Serializer का विस्तार है)।

डेटाबेस सत्यापन

उपयोगकर्ता के सबमिट किए गए डेटा पर चलाई गई हर डेटाबेस खोज के लिए लौटाया जाता है। GET /v3/session/{sessionId}/decision/ में database_validations[] के रूप में दिखता है। स्रोत: database_validation/serializers/database_validation.py:21-142 (DatabaseValidationV3Serializer, जो DatabaseValidationV2Serializer का विस्तार है)।

प्रश्नावली रिस्पॉन्स

हर प्रश्नावली सबमिशन के लिए लौटाई जाती है। KYC और KYB, दोनों सत्रों के लिए यह GET /v3/session/{sessionId}/decision/ में questionnaire_responses[] के रूप में दिखती है। स्रोत: questionnaires/serializers/questionnaire.py:591-597 (QuestionnaireResponseV3Serializer, जो questionnaires/serializers/questionnaire.py:520-588 पर QuestionnaireResponseSerializer को विस्तारित करता है)।

ई-हस्ताक्षर

हर ई-हस्ताक्षर चरण के हर साइनर के लिए लौटाया जाता है। KYC और KYB, दोनों सत्रों के लिए यह GET /v3/session/{sessionId}/decision/ में signatures[] के रूप में दिखता है, और केवल तब जब वर्कफ़्लो में यह चरण हो। अन्य रिपोर्ट ऑब्जेक्ट से अलग, इसका status हस्ताक्षर का चरण है और परिणाम verdict में है, और इसके warnings[] आइटम { code, node_id } हैं, न कि चेतावनी ऑब्जेक्ट। ई-हस्ताक्षर रिपोर्ट में पूरा उदाहरण और हर नेस्टेड फ़ील्ड है।

आयु अनुमान

यह स्टैंडअलोन आयु अनुमान API (POST /v3/age-estimation/) से लौटाया जाता है। रिस्पॉन्स में Liveness check के आकार का एक उपसमुच्चय age_estimation एन्वेलप के अंतर्गत होता है: status, method, score, age_estimation, warnings। इसके साथ केवल स्टैंडअलोन के लिए एक user_image चेहरा-डिटेक्शन ब्लॉक भी होता है; इसमें reference_image, video_url, matches, face_quality या face_luminance शामिल नहीं होते। वर्कफ़्लो सत्रों में कोई अलग सूची नहीं होती: अनुमानित आयु GET /v3/session/{sessionId}/decision/ में liveness_checks[].age_estimation के रूप में दिखती है। स्रोत: apis/serializers/age_estimation.py:50-55 (AgeEstimationResponseSerializer), एन्वेलप apis/views/age_estimation.py:138-174 में बनाया जाता है।

बायोमेट्रिक प्रमाणीकरण

बायोमेट्रिक प्रमाणीकरण वही लाइवनेस + चेहरा मिलान पाइपलाइन चलाता है जो स्टैंडर्ड KYC में इस्तेमाल होती है, लेकिन इसे कैप्चर किए गए चेहरे की तुलना किसी मौजूदा उपयोगकर्ता की संदर्भ छवि से करने के लिए कॉन्फ़िगर किया गया है, न कि ताज़ा OCR किए गए दस्तावेज़ पोर्ट्रेट से। कोई समर्पित सीरियलाइज़र नहीं है: GET /v3/session/{sessionId}/decision/ liveness_checks[] और face_matches[] के अंतर्गत स्टैंडर्ड लाइवनेस जाँच और चेहरा मिलान ऑब्जेक्ट लौटाता है। सत्र का वर्कफ़्लो workflow_type = "biometric_authentication" के साथ कॉन्फ़िगर होता है (WorkflowTypeChoices, common/config/choices.py:636)।

KYB रजिस्ट्री

रजिस्ट्री से पुष्ट हर कंपनी के लिए KYB वर्कफ़्लो में लौटाया जाता है। व्यवसाय सत्रों के लिए यह GET /v3/session/{sessionId}/decision/ में registry_checks[] के रूप में दिखता है। स्रोत: kyb/serializers/kyb.py:939-964 (RegistryCheckV3Serializer)।

कंपनी ऑब्जेक्ट

स्रोत: kyb/serializers/kyb.py:220-321 (KYBCompanyResponseSerializer)।

KYB दस्तावेज़

प्रत्येक नोड के लिए लौटाया जाता है जो KYB सहायक दस्तावेज़ एकत्र करता है। व्यवसाय सत्रों के लिए GET /v3/session/{sessionId}/decision/ में document_verifications[] के रूप में दिखता है: प्रत्येक node_id के लिए एक प्रविष्टि, जिसमें items[] में अपलोड किया गया हर दस्तावेज़ सूचीबद्ध होता है। स्रोत: kyb/serializers/kyb.py:1053-1068 (DocumentVerificationV3Serializer); प्रत्येक आइटम kyb/serializers/kyb.py:811-851 (KYBDocumentResponseSerializer) का अनुसरण करता है।

KYB दस्तावेज़ आइटम ऑब्जेक्ट

KYB प्रमुख व्यक्ति

KYB वर्कफ़्लो में प्रत्येक प्रमुख व्यक्ति नोड के लिए लौटाया जाता है। व्यवसाय सत्रों के लिए GET /v3/session/{sessionId}/decision/ में key_people_checks[] के रूप में दिखता है। स्रोत: kyb/serializers/kyb.py:967-1050 (KeyPeopleCheckV3Serializer)।

निर्णय-स्तर के फ़ील्ड

ये कुंजियाँ GET /v3/session/{sessionId}/decision/ पर सुविधा ऐरे के साथ और webhook के decision के भीतर होती हैं। इन्हें कैसे पढ़ें, इसके लिए सत्र प्राप्त करें देखें।

बायोमेट्रिक सहमति

हर उपयोगकर्ता सत्यापन निर्णय और सत्र webhook में एक ही biometric_consent ऑब्जेक्ट होता है (ऐरे नहीं). इसमें लिखा होता है कि सत्र को स्पष्ट बायोमेट्रिक सहमति चाहिए थी या नहीं, क्यों चाहिए थी, और उत्तर का साक्ष्य क्या है. जब सत्र का मूल्यांकन कभी नहीं हुआ, उदाहरण के लिए चेहरा कैप्चर के बिना वर्कफ़्लो, तब यह null होता है. स्रोत: BiometricConsentDecisionSerializer (sessions/serializers/biometric_consent.py). किन परिस्थितियों में यह चरण दिखता है और हर मामले का क्या अर्थ है, यह बायोमेट्रिक सहमति में समझाया गया है. जिन फ़ील्ड का कोई दर्ज मान नहीं है, वे null होते हैं, कभी खाली स्ट्रिंग नहीं. Illinois का एक सत्र, जिसे 4.10.0 से कम संस्करण के नेटिव SDK ने चलाया और जिसने चरण के बिना सेल्फ़ी कैप्चर की:
एक व्यक्ति जिसका VPN एग्ज़िट US के बाहर था, और जिसने होस्टेड फ़्लो में सहमति दी:

स्टेटस एनम संदर्भ

दो संबंधित मान-समूह status फ़ील्ड का नाम साझा करते हैं। इस पेज की हर सुविधा-स्तरीय रिपोर्ट ऑब्जेक्ट सुविधा-स्तरीय एनम इस्तेमाल करता है, जबकि पैरेंट सत्र का टॉप-लेवल status व्यापक सत्र एनम इस्तेमाल करता है।

सुविधा-स्तरीय स्टेटस

हर रिपोर्ट ऑब्जेक्ट के status फ़ील्ड में इस्तेमाल होता है। स्रोत: common/config/choices.py:343-348 (FeatureStatusChoices)। फ़ोन, ईमेल और पहचान सत्यापन में, जब उनका चरण समय-सीमा समाप्त होने पर टाइम आउट हो जाए, तो अतिरिक्त रूप से Expired भी दिखाई दे सकता है (PhoneStatusChoices common/config/choices.py:377-382 पर, और EmailStatusChoices common/config/choices.py:434-439 पर)।

सत्र-स्तरीय स्टेटस

पैरेंट सत्र के टॉप-लेवल status में इस्तेमाल होता है। स्रोत: common/config/choices.py:106-117 (StatusChoices)।
अंतिम सत्र मान Approved, Declined, In Review, Expired, Kyc Expired और Abandoned हैं। कोई सत्र तब भी अपने समग्र निर्णय तक पहुँच सकता है जब कोई व्यक्तिगत सुविधा In Review पर बनी रहे।
अंतिम संशोधन 14 नवंबर 2026