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

अवलोकन

हर सुविधा-वार रिपोर्ट 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 चिप, या chip_protocol: "jpki" के माध्यम से JPKI से पढ़ा गया जापान का My Number Card। यह 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 को विस्तारित करता है)।

चेहरा मिलान

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

चेहरा खोज

स्टैंडअलोन चेहरा खोज API (POST /v3/face-search/) यह डेटा लौटाता है। Face Search /v3/session/{sessionId}/decision/ में कभी भी बहुवचन array के रूप में नहीं आता। जब save_api_request=true के साथ सहेजा जाता है, तब सत्र वहाँ features[] में FACE_SEARCH entry के रूप में और एक liveness_checks[] आइटम के रूप में दिखता है, जिसमें सहेजे गए matches होते हैं। स्रोत: apis/serializers/face_search.py:8-79 (FaceSearchResponseSerializer, जो FaceSearchDetailsSerializer को wrap करता है); match dicts 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 पर बनी रहे।
अंतिम संशोधन 7 नवंबर 2026