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

KYC और KYB सहायता

यह endpoint उपयोगकर्ता सत्यापन (KYC) और व्यवसाय सत्यापन (KYB) दोनों सत्रों के लिए काम करता है। रिस्पॉन्स में हमेशा एक शीर्ष-स्तरीय फ़ील्ड session_kind होता है:
  • "user": उपयोगकर्ता सत्यापन (KYC) सत्र। रिस्पॉन्स में id_verifications, liveness_checks, face_matches, nfc_verifications, poa_verifications और database_validations होते हैं।
  • "business": व्यवसाय सत्यापन (KYB) सत्र। रिस्पॉन्स में registry_checks, document_verifications और key_people_checks होते हैं।
दोनों प्रकार के सत्र aml_screenings, phone_verifications, email_verifications, questionnaire_responses, ip_analyses, document_ai_documents, bank_verifications, reviews और contact_details साझा करते हैं, साथ ही सामान्य शीर्ष-स्तरीय फ़ील्ड (session_id, session_number, session_url, status, workflow_id, vendor_data, metadata, callback, features, expected_details, created_at, expires_at) भी। Didit session_id को दोनों सत्र प्रकारों के विरुद्ध मिलाता है (पहले उपयोगकर्ता सत्यापन, फिर व्यवसाय सत्यापन (KYB)) और जो मेल खाता है, वही लौटाता है। UUID प्रति एप्लिकेशन अद्वितीय होते हैं, इसलिए कोई अस्पष्टता नहीं है। प्रकार-विशिष्ट सुविधाओं का पूरा मैट्रिक्स देखने के लिए सत्र अवलोकन पढ़ें।

उदाहरण

रिस्पॉन्स (संक्षिप्त):

आपकी ओर से रिस्पॉन्स को संभालना

स्थिति, निर्णय ट्रेस और समीक्षा फ़ील्ड

हर निर्णय बताता है कि उसकी status कैसे तय हुई।

बायोमेट्रिक डेटा प्रतिधारण

biometric_retention हमेशा मौजूद रहता है। deletes_at वह तिथि है जिस दिन सत्र का लाइव बायोमेट्रिक डेटा हटाया जाता है, और jurisdictions उन US राज्यों की सूची देता है जिनके बायोमेट्रिक नियम उस व्यक्ति के लिए हटाने की सीमा तय करते हैं (राज्य अज्ञात होने पर US)। जब तक कोई तिथि लागू न हो, deletes_at null होता है।

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

जब वर्कफ़्लो में स्थान सत्यापन चरण हो, तो निर्णय में दो सरणियाँ होती हैं। geolocation_checks[] में हर चरण के लिए एक आइटम होता है: उसका स्वीकृत प्रयास, परिणाम, निर्देशांक और उनकी सटीकता, IP स्थान और फ़ाइल पर मौजूद पते के विरुद्ध जाँचें, तथा चरण की warnings। geolocation_attempts[] हर चरण के हर प्रयास को सबसे पुराने से नए क्रम में सूचीबद्ध करता है, साथ में यह कि वह कब प्राप्त हुआ। जिन वर्कफ़्लो में यह चरण नहीं है, उनमें दोनों null लौटते हैं। हर फ़ील्ड और परिणाम स्थान सत्यापन रिपोर्ट में दिया गया है।

वर्कफ़्लो राउटिंग इवेंट

?include=events सत्र की इवेंट टाइमलाइन जोड़ता है। चरण और स्थिति में होने वाले बदलावों के साथ, जो वर्कफ़्लो ब्रांच नोड्स से होकर गुज़रता है, वह हर राउटिंग निर्णय के लिए एक इवेंट लिखता है। इससे कोई इंटीग्रेशन (या Console की टाइमलाइन) वर्कफ़्लो ग्राफ़ को हाथ से दोबारा चलाए बिना समझा सकता है कि सत्र किसी खास परिणाम पर क्यों समाप्त हुआ: दोनों इवेंट में बाकी सभी इवेंट की तरह sent_at मिलीसेकंड में होता है, और इनमें component, feature_step या step नहीं होते: ये वर्कफ़्लो इंजन से आते हैं, उपयोगकर्ता के डिवाइस से नहीं। “else” ब्रांच (यानी बिना शर्त वाली ब्रांच) को मेल खाती ब्रांच माना जाता है; fallback केवल तब true होता है जब कुछ भी मेल न खाए। जिन नोड्स में केवल एक आउटगोइंग एज है, वे कोई निर्णय नहीं लेते और कोई इवेंट नहीं छोड़ते। इसी शेप में workflow_terminal_node_id भी दिखता है: यह सबसे हाल के रिकॉर्ड किए गए उस वर्कफ़्लो स्टेटस नोड का node_id है जिसने सत्र का स्टेटस सेट किया, या null यदि ऐसा कोई नोड ID रिकॉर्ड नहीं हुआ है। यह वर्कफ़्लो का ऐतिहासिक रिकॉर्ड है। मैन्युअल स्वीकृतियाँ, अस्वीकृतियाँ और पुनः सबमिशन इसे साफ़ नहीं करते; बाद का कोई वर्कफ़्लो स्टेटस नोड इसकी जगह लेता है। उदाहरण के लिए, अगर वर्कफ़्लो किसी सत्र को In Review नोड पर भेजता है और समीक्षक बाद में उसे स्वीकृत कर देता है, तो मौजूदा status Approved होता है, जबकि workflow_terminal_node_id अब भी In Review नोड की पहचान करता है। पुनः सबमिशन चलते समय भी यह भरा रह सकता है। वर्कफ़्लो के परिणामों को बाद के मैन्युअल निर्णयों से अलग पहचानने के लिए मौजूदा status और इवेंट व activity_reviews टाइमलाइन पढ़ें।

पिछले सबमिशन (?include=resubmissions)

पुनः सबमिशन उपयोगकर्ता को आपके चुने हुए चरणों पर वापस भेजता है, और उन चरणों ने पहले जो लौटाया था उसे बनाए रखता है। ?include=resubmissions एक resubmissions एरे जोड़ता है, जिसमें सबसे पुरानी एंट्री पहले होती है और हर पुनः सबमिशन अनुरोध के लिए एक एंट्री होती है। हर एंट्री में वे परिणाम होते हैं जिन्हें उस अनुरोध ने बदला था, ताकि आप हमेशा पढ़ सकें कि उपयोगकर्ता ने पहले क्या सबमिट किया था। यह उपयोगकर्ता (KYC) और व्यवसाय (KYB) दोनों सत्रों के लिए काम करता है, और आप इसे इवेंट के साथ जोड़ सकते हैं (?include=events,resubmissions)। पैरामीटर के बिना रिस्पॉन्स नहीं बदलता। मौजूदा परिणाम (id_verifications और शीर्ष स्तर की बाकी कुंजियाँ) हमेशा सबसे नए सबमिशन का वर्णन करते हैं। जो चरण वापस नहीं भेजे गए, उनका वहाँ एक ही परिणाम रहता है।
सत्र हटाने पर उसके हर सबमिशन के परिणाम भी हट जाते हैं।

पहचान सत्यापन के तरीके

हर id_verifications[] आइटम बताता है कि तीन पहचान सत्यापन के तरीकों में से किसने उसे बनाया, ताकि आप दस्तावेज़ पढ़ने, रजिस्ट्री लुकअप और वॉलेट साइन-इन को केवल उन फ़ील्ड्स से अंदाज़ा लगाए बिना अलग पहचान सकें जो संयोग से भरे हैं: दस्तावेज़ सत्र document और documentary रिपोर्ट करता है और बाकी को null छोड़ता है, इसलिए मौजूदा इंटीग्रेशन को कोई बदलाव नहीं चाहिए। फ़ील्ड-दर-फ़ील्ड प्रकार डेटा मॉडल में हैं।

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

उपयोगकर्ता सत्यापन निर्णयों में biometric_consent ऑब्जेक्ट होता है: सत्र को स्पष्ट बायोमेट्रिक सहमति चाहिए थी या नहीं, वह trigger जिसने इसे माँगा, उत्तर का status और उसका साक्ष्य। दो मान बताते हैं कि सहमति एकत्र नहीं हुई: सहमति का चरण कब दिखता है और हर मान का क्या अर्थ है, यह बायोमेट्रिक सहमति में बताया गया है; हर फ़ील्ड डेटा मॉडल में है।

बैंक सत्यापन

जब वर्कफ़्लो में बैंक सत्यापन चरण होता है, तो निर्णय में bank_verifications[] शामिल होता है, जो दोनों सत्र प्रकारों के लिए लागू है: हर चरण के लिए एक आइटम, और जब तक कोई चरण इसे उत्पन्न नहीं करता, तब तक null। बैंक साइन-इन और खाता जाँच में अंतर करने के लिए method पढ़ें, ownership.method नहीं: ownership.method वह नाम-तुलना है जिसने स्कोर दिया। हर फ़ील्ड इस endpoint के रिस्पॉन्स की BankVerificationResult स्कीमा में है।

ई-हस्ताक्षर

जब वर्कफ़्लो में ई-हस्ताक्षर चरण होता है, तो निर्णय में signatures[] शामिल होता है, जो दोनों सत्र प्रकारों के लिए लागू है। इसमें हर हस्ताक्षरकर्ता के लिए एक आइटम होता है: उपयोगकर्ता सत्यापन के लिए एक, और व्यवसाय सत्यापन के लिए हर उस प्रमुख व्यक्ति के लिए एक जो हस्ताक्षर करता है। बिना इस चरण वाले वर्कफ़्लो इस कुंजी को बिल्कुल नहीं लौटाते। अपनी API कुंजी के साथ पथों से फ़ाइलें डाउनलोड करें। हर फ़ील्ड के लिए ई-हस्ताक्षर रिपोर्ट देखें।

त्रुटियाँ

संबंधित

प्राधिकरण

x-api-key
string
header
आवश्यक

आपकी एप्लिकेशन की API कुंजी, Business Console में Developers -> API keys से। प्राथमिक कुंजी के पास पूर्ण एक्सेस होता है। एक नामित कुंजी को स्कोप किया जा सकता है: प्रति संसाधन none, read या write, कुछ वर्कफ़्लो या स्वीकृत सत्रों तक सीमित, IP पतों की सूची तक सीमित, और समाप्ति तिथि तक सीमित। 401 का अर्थ है कि कुंजी गलत है, निरस्त कर दी गई है या उसकी समय-सीमा समाप्त हो गई है; 403 का अर्थ है कि कोई कुंजी नहीं भेजी गई थी, कुंजी के पास इस संसाधन या कार्रवाई का एक्सेस नहीं है, या अनुरोध उसकी IP सूची से बाहर के पते से आया था; सत्र रूट पर 404 का अर्थ है कि सत्र कुंजी के वर्कफ़्लो या स्थितियों से बाहर है। मीडिया एक्सेस के बिना एक कुंजी को छवि, वीडियो और PDF URL null के रूप में प्राप्त होते हैं, और सत्र write के बिना एक कुंजी को सत्र लिंक और token null के रूप में प्राप्त होते हैं। देखें https://docs.didit.me/console/api-keys।

पथ पैरामीटर

sessionId
string<uuid>
आवश्यक

उस सत्यापन सत्र का UUID जिसका निर्णय आप प्राप्त करना चाहते हैं। यह POST /v3/session/ द्वारा लौटाया गया session_id है। यही पाथ उपयोगकर्ता सत्यापन (KYC) और व्यवसाय सत्यापन (KYB) दोनों सत्रों के लिए काम करता है — सर्वर दोनों सत्र प्रकारों में id को रिज़ॉल्व करता है।

एक मान्य UUID होना चाहिए। यह रूट केवल सही प्रारूप वाले UUID से मेल खाता है, इसलिए किसी भी एप्लिकेशन कोड के चलने से पहले URL राउटर द्वारा गलत प्रारूप वाले मान को अस्वीकार कर दिया जाता है और रिस्पॉन्स नीचे दिखाए गए JSON {"detail": ...} एनवलप के बजाय 404 HTML पेज होता है। क्लाइंट-साइड पर UUID प्रारूप को सत्यापित करें ताकि आप इनपुट त्रुटि और वास्तविक अनुपलब्ध-सत्र 404 के बीच अंतर कर सकें।

उदाहरण:

"11111111-2222-3333-4444-555555555555"

क्वेरी पैरामीटर

include
enum<string>

अतिरिक्त payload अनुभागों की अल्पविराम से अलग की गई सूची। समर्थित मान: events और resubmissions, अकेले या एक साथ (events,resubmissions)। जब include=events पास किया जाता है, तो रिस्पॉन्स में अतिरिक्त रूप से सत्र इवेंट टाइमलाइन शामिल होती है (events, जिसमें Retrieve Session पेज पर वर्णित WORKFLOW_BRANCH_EVALUATED / WORKFLOW_STATUS_NODE_REACHED रूटिंग इवेंट शामिल हैं), पूर्ण गतिविधि लॉग (activity_reviews), ब्लॉकलिस्ट फ़्लैग (blocklisted), प्रति सत्र cost_breakdown, वर्कफ़्लो मेटाडेटा (workflow_type, workflow_version, workflow_version_id, और workflow_terminal_node_id - अंतिम रिकॉर्ड किया गया वर्कफ़्लो स्थिति नोड जिसने सत्र स्थिति सेट की थी, या यदि कोई रिकॉर्ड नहीं किया गया है तो null; ऐतिहासिक उत्पत्ति जिसे मैन्युअल स्वीकृतियों, अस्वीकृतियों या पुनः सबमिशन द्वारा साफ़ नहीं किया जाता है, और बाद के वर्कफ़्लो स्थिति नोड द्वारा प्रतिस्थापित किया जाता है), और सत्र मेटाडेटा (api_service — स्ट्रिंग या null, केवल स्टैंडअलोन-API सत्रों के लिए सेट; session_type — API, HOSTED, या MIGRATED; has_device_nfc_support — बूलियन)। सामान्य संरचना की तुलना में दो फ़ील्ड बदलते हैं: शीर्ष-स्तरीय session_kind डिस्क्रिमिनेटर हटा दिया जाता है (इवेंट संरचना केवल उपयोगकर्ता सत्रों के लिए मौजूद होती है), और features सरणी सामान्य स्ट्रिंग्स से {feature, node_id} ऑब्जेक्ट्स में बदल जाती है — जहाँ ईमेल सुविधा को EMAIL_VERIFICATION के बजाय EMAIL के रूप में रिपोर्ट किया जाता है। यह विस्तृत संरचना मुख्य रूप से Didit Console द्वारा उपयोग की जाती है; अधिकांश API इंटीग्रेशन को इस पैरामीटर को छोड़ देना चाहिए। KYB सीमा: include=events केवल उपयोगकर्ता (KYC) सत्रों पर लागू होता है। व्यावसायिक सत्र (session_kind = "business") हमेशा मानक व्यावसायिक निर्णय संरचना लौटाते हैं — व्यावसायिक सत्रों के लिए events, activity_reviews, blocklisted, cost_breakdown और अतिरिक्त workflow_*/सत्र मेटाडेटा कभी नहीं लौटाए जाते हैं, और उनकी features सरणी एक सामान्य स्ट्रिंग सरणी ही रहती है। include=resubmissions के साथ (उपयोगकर्ता और व्यावसायिक सत्र दोनों के लिए) रिस्पॉन्स में resubmissions भी शामिल होता है: प्रति पुनः सबमिशन अनुरोध एक प्रविष्टि, सबसे पुरानी पहले, प्रत्येक में number, created_at, previous_status, nodes, reasons, requested_by और results (अनुरोध से पहले पुनः सबमिट किए गए चरणों ने क्या लौटाया था, उन्हीं कुंजियों के तहत और वर्तमान परिणामों की समान संरचना में)। प्रत्येक cost_breakdown आइटम में usage_type, price, details और created_at शामिल होते हैं: फिर से चलने वाले पुनः सबमिट किए गए चरण को एक नए आइटम के रूप में बिल किया जाता है।

उपलब्ध विकल्प:
events,
resubmissions,
events,resubmissions
उदाहरण:

"events"

प्रतिक्रिया

पूर्ण निर्णय रिपोर्ट। session_kind दोनों आकारों में अंतर करता है: user सत्र नीचे दिखाए गए KYC फ़ीचर ऐरे ले जाते हैं; business सत्र इसके बजाय साझा ऐरे के साथ registry_checks, document_verifications और key_people_checks ले जाते हैं। वर्कफ़्लो द्वारा उस फ़ीचर को चलाने तक फ़ीचर ऐरे null होते हैं; मीडिया URL अल्पकालिक प्री-साइन्ड लिंक होते हैं।

session_id
string<uuid>

सत्र का विशिष्ट पहचानकर्ता।

session_kind
enum<string>

यह इंगित करने वाला डिस्क्रिमिनेटर कि यह उपयोगकर्ता सत्यापन (KYC) सत्र है या व्यवसाय सत्यापन (KYB) सत्र। जब user हो, तो KYC फ़ीचर ऐरे (id_verifications, nfc_verifications, liveness_checks, face_matches, poa_verifications, document_ai_documents, database_validations, ...) लागू होते हैं और व्यावसायिक ऐरे अनुपस्थित होते हैं। जब business हो, तो payload में registry_checks, document_verifications, key_people_checks के साथ-साथ साझा ऐरे (aml_screenings, phone_verifications, email_verifications, ip_analyses, questionnaire_responses) शामिल होते हैं। include=events पास होने पर छोड़ दिया जाता है — events संरचना केवल उपयोगकर्ता सत्रों के लिए मौजूद होती है, इसलिए उस वेरिएंट से डिस्क्रिमिनेटर हटा दिया जाता है।

उपलब्ध विकल्प:
user,
business
shared_from_session
string<uuid> | null

POST /v3/session/import-shared/ के साथ क्लोन किए गए सत्र के लिए: स्रोत एप्लिकेशन में मूल सत्र का session_id। अन्य सभी सत्रों के लिए null। include=events पास किए जाने पर छोड़ दिया जाता है।

shared_from_session_number
integer | null

स्रोत सत्र का session_number जब इस सत्र को आपके संगठन के किसी अन्य एप्लिकेशन से इंपोर्ट किया गया था। अन्यथा null।

session_number
integer | null

सत्र की संख्या।

session_url
string<uri> | null

सत्र का URL।

status
enum<string>

सत्र की समग्र जीवनचक्र स्थिति — समेकित वर्कफ़्लो परिणाम। अंतिम मान Approved, Declined, In Review, Expired, Kyc Expired, और Abandoned हैं; Not Started, In Progress, Awaiting User, और Resubmitted इंगित करते हैं कि सत्र अभी भी वर्कफ़्लो से गुज़र रहा है।

उपलब्ध विकल्प:
Not Started,
In Progress,
Awaiting User,
In Review,
Approved,
Declined,
Resubmitted,
Expired,
Kyc Expired,
Abandoned
status_override
object | null

समीक्षक द्वारा मैन्युअल रूप से status सेट किए जाने पर मौजूद होता है। स्थिति स्वचालित होने पर null होता है। इसका उपयोग मैन्युअल स्वीकृति को स्वचालित स्वीकृति से अलग पहचानने के लिए करें।

decision_trace
object

स्थिति तक कैसे पहुँचा गया: इसे किसने सेट किया और किन चेतावनियों ने ऐसा किया।

linked_records
object | null

सत्र से जुड़े अन्य रिकॉर्ड का सारांश। दिखाने के लिए कुछ न होने पर, और उन वर्कफ़्लो के लिए जो आयु आश्वासन मानक घोषित करते हैं, null होता है।

workflow_id
string<uuid> | null

वर्कफ़्लो समूह का स्थिर पहचानकर्ता जिसने यह सत्र बनाया। वर्कफ़्लो संस्करणित होते हैं — यह मान विशिष्ट संस्करण की नहीं, बल्कि स्वयं वर्कफ़्लो की पहचान करता है।

features
string[]

इस सत्र के लिए कॉन्फ़िगर की गई सत्यापन सुविधाओं की सूची, प्रदर्शन नामों के रूप में: ID_VERIFICATION, NFC, LIVENESS, FACE_MATCH, POA, PHONE, EMAIL_VERIFICATION, AML, IP_ANALYSIS, DATABASE_VALIDATION, QUESTIONNAIRE, AGE_ESTIMATION, FACE_SEARCH, GEOLOCATION (स्थान सत्यापन) (व्यवसाय सत्यापन सत्र KYB सुविधा सेट का उपयोग करते हैं: KYB_REGISTRY, KYB_DOCUMENTS, KYB_KEY_PEOPLE, AML, PHONE, EMAIL_VERIFICATION, IP_ANALYSIS, QUESTIONNAIRE)। include=events के साथ प्रत्येक प्रविष्टि एक सादे स्ट्रिंग के बजाय एक ऑब्जेक्ट {feature, node_id} बन जाती है, और ईमेल सुविधा का नाम बदल दिया जाता है: यह यहाँ उपयोग किए गए EMAIL_VERIFICATION के बजाय इवेंट मोड में EMAIL के रूप में दिखाई देती है।

सत्र की सुविधा।

vendor_data
string | null

सत्र का वेंडर डेटा।

metadata
object | null

सत्र का मेटाडेटा।

expected_details
object | null

सत्र निर्माण के समय दिए गए अपेक्षित विवरण — निकाले गए डेटा (KYC) के विरुद्ध क्रॉस-सत्यापन के लिए या कंपनी रजिस्ट्री खोज (KYB) को पहले से भरने के लिए उपयोग किए जाते हैं। जो कुंजियाँ प्रदान की गई थीं, उन्हें ठीक वैसे ही लौटाता है; कोई प्रदान न किए जाने पर null। KYC सत्रों में व्यक्ति के फ़ील्ड होते हैं; व्यवसाय (KYB) सत्रों में company_name, registry_country और registration_number होते हैं।

contact_details
object | null

सत्र बनाते समय प्रदान किए गए संपर्क विवरण (अधिसूचना ईमेल, पहले से भरे फ़ोन/ईमेल सत्यापन और संचार भाषा के लिए उपयोग किए जाते हैं)। जब न तो कोई ईमेल और न ही कोई फ़ोन नंबर प्रदान किया गया था, तब null होता है।

callback
string<uri> | null

सत्र का कॉलबैक URL।

id_verifications
object[] | null

वर्कफ़्लो ग्राफ़ में पहचान-दस्तावेज़ चरणों द्वारा निर्मित पहचान सत्यापन (OCR) रिपोर्टों की ऐरे। हमेशा एक JSON ऐरे — id_verifications[0] पढ़ें और पुनरावृति करें यदि आपका वर्कफ़्लो एक से अधिक पहचान जाँच चला सकता है (उदाहरण के लिए प्राथमिक जाँच और साथ ही स्टेप-अप)। तब तक null जब तक कम से कम एक पहचान चरण ने डेटा उत्पन्न न किया हो। प्रत्येक आइटम पूर्ण रिपोर्ट है, जिसमें node_id, सुविधा-स्तरीय status, निकाले गए दस्तावेज़ फ़ील्ड, छवि URLs, गुणवत्ता स्कोर, MRZ, पता पार्सिंग, क्रॉस-सत्र मिलान, और warnings[] शामिल हैं।

nfc_skip_reason
enum<string> | null

NFC चिप सत्यापन क्यों नहीं चला, जब भी वर्कफ़्लो में NFC चरण शामिल होता है तब पॉप्युलेट होता है। NFC लंबित रहने या चिप वास्तव में पढ़े जाने पर null। मान: USER_SKIPPED - उपयोगकर्ता ने NFC-सक्षम डिवाइस पर छोड़ना चुना (allow_nfc_skip द्वारा अनुमत); DOCUMENT_WITHOUT_CHIP - दस्तावेज़ में कोई पठनीय NFC चिप नहीं है (ICAO 9303 इलेक्ट्रॉनिक दस्तावेज़ नहीं है); CHIP_CERTIFICATE_UNAVAILABLE - दस्तावेज़ की जारी अवधि को कवर करने वाला जारीकर्ता देश का हस्ताक्षर प्रमाणपत्र (CSCA) अनुपलब्ध है, इसलिए चिप हस्ताक्षर सत्यापित नहीं किया जा सकता; DEVICE_WITHOUT_NFC - डिवाइस ने कोई NFC रीडर रिपोर्ट नहीं किया; INTEGRATION_WITHOUT_NFC_ACCESS - सत्यापन मूल SDK के बिना चला (उदा. वेब ब्राउज़र में), जिसके पास फ़ोन के NFC रीडर तक कोई पहुँच नहीं है; MRZ_KEY_UNAVAILABLE - चिप एक्सेस कुंजी दस्तावेज़ के MRZ से प्राप्त नहीं की जा सकी; JPKI_UNAVAILABLE - दस्तावेज़ जापान का माय नंबर कार्ड है, जिसकी चिप JPKI के माध्यम से पढ़ी जाती है, और इस सत्यापन के लिए JPKI उपलब्ध नहीं था: यह सक्षम नहीं है, या ऐप का मूल SDK माय नंबर कार्ड नहीं पढ़ सकता है।

उपलब्ध विकल्प:
USER_SKIPPED,
DOCUMENT_WITHOUT_CHIP,
CHIP_CERTIFICATE_UNAVAILABLE,
DEVICE_WITHOUT_NFC,
INTEGRATION_WITHOUT_NFC_ACCESS,
MRZ_KEY_UNAVAILABLE,
JPKI_UNAVAILABLE
nfc_verifications
object[] | null

वर्कफ़्लो ग्राफ़ में NFC चरणों द्वारा निर्मित NFC / ePassport रिपोर्टों का Array। यह हमेशा एक JSON array होता है, कभी भी एकल nfc ऑब्जेक्ट नहीं — nfc_verifications[0] पढ़ें और पुनरावृति (iterate) करें यदि आपका वर्कफ़्लो NFC को एक से अधिक बार चला सकता है। तब तक null जब तक कम से कम एक NFC चरण ने डेटा उत्पन्न न किया हो। प्रत्येक आइटम पूर्ण रिपोर्ट है, जिसमें node_id, सुविधा-स्तरीय status, chip_protocol, chip_data, authenticity (SOD + DG अखंडता), certificate_summary, और warnings[] शामिल हैं। जापान माय नंबर कार्ड को ICAO 9303 के बजाय JPKI के माध्यम से पढ़ा जाता है: इसके आइटम में chip_protocol: "jpki" होता है, यह अपने साक्ष्य jpki के तहत रखता है, और ICAO फ़ील्ड को null छोड़ता है। जब NFC चरण को ऑफ़र किए जाने से पहले ही बायपास कर दिया गया था (चिप रहित दस्तावेज़, अनुपलब्ध प्रमाणपत्र, कोई NFC क्षमता रिपोर्ट नहीं की गई, अपठनीय MRZ कुंजी, माय नंबर कार्ड के लिए JPKI अनुपलब्ध), तो यह null रहता है और nfc_skip_reason बताता है कि ऐसा क्यों हुआ; चरण में ही छोड़ दिया जाना (उपयोगकर्ता ने स्किप टैप किया, या स्कैन के समय रीडर अनुपलब्ध निकला) फिर भी is_nfc_skipped: true के साथ एक रिपोर्ट उत्पन्न करता है।

liveness_checks
object[] | null

वर्कफ़्लो ग्राफ़ में लाइवनेस चरणों द्वारा निर्मित लाइवनेस रिपोर्टों का ऐरे। हमेशा एक JSON ऐरे — कभी भी एकल liveness ऑब्जेक्ट नहीं। तब तक null जब तक कम से कम एक लाइवनेस चरण ने डेटा उत्पन्न न किया हो। प्रत्येक आइटम पूर्ण रिपोर्ट है, जिसमें node_id, सुविधा-स्तरीय status, method, score, reference_image, video_url, वैकल्पिक age_estimation, क्रॉस-सत्र matches[], और warnings[] शामिल हैं।

face_matches
object[] | null

वर्कफ़्लो ग्राफ़ में चेहरा मिलान चरणों द्वारा निर्मित चेहरा मिलान रिपोर्टों की ऐरे। हमेशा एक JSON ऐरे — कभी भी एकल face_match ऑब्जेक्ट नहीं। तब तक null जब तक कम से कम एक चेहरा मिलान चरण ने डेटा उत्पन्न न किया हो। प्रत्येक आइटम पूर्ण रिपोर्ट है, जिसमें node_id, सुविधा-स्तरीय status, समानता score, source_image, target_image, और warnings[] शामिल हैं।

phone_verifications
object[] | null

फ़ोन सत्यापन रिपोर्टों की ऐरे — हमेशा एक JSON ऐरे, कभी भी एकल phone ऑब्जेक्ट नहीं। तब तक null जब तक कम से कम एक फ़ोन चरण ने डेटा उत्पन्न न किया हो। प्रत्येक आइटम पूर्ण रिपोर्ट है, जिसमें node_id, सुविधा-स्तरीय status, फ़ोन नंबर और देश का मेटाडेटा, lifecycle[], matches[], और warnings[] शामिल हैं।

email_verifications
object[] | null

ईमेल सत्यापन रिपोर्टों की ऐरे — हमेशा एक JSON ऐरे, कभी भी एकल email ऑब्जेक्ट नहीं। तब तक null जब तक कम से कम एक ईमेल चरण ने डेटा उत्पन्न न किया हो। प्रत्येक आइटम पूर्ण रिपोर्ट है, जिसमें node_id, सुविधा-स्तरीय status, ईमेल पता, ब्रीच डेटा, lifecycle[], matches[], और warnings[] शामिल हैं।

poa_verifications
object[] | null

पते का प्रमाण (POA) रिपोर्टों की ऐरे — हमेशा एक JSON ऐरे, कभी भी एकल poa ऑब्जेक्ट नहीं। तब तक null जब तक कम से कम एक POA चरण ने डेटा उत्पन्न न किया हो। प्रत्येक आइटम पूर्ण रिपोर्ट है, जिसमें node_id, सुविधा-स्तरीय status, दस्तावेज़ फ़ाइल URL, जारीकर्ता, तिथियाँ, पार्स किया गया पता, और warnings[] शामिल हैं।

document_ai_documents
object[] | null

वर्कफ़्लो नोड द्वारा समूहीकृत Document AI रिपोर्टें — हमेशा एक JSON ऐरे, कभी भी एकल ऑब्जेक्ट नहीं। तब तक null जब तक कि कम से कम एक Document AI चरण ने डेटा उत्पन्न न किया हो। केवल तभी मौजूद होता है जब session_kind = user हो। प्रत्येक आइटम एक नोड समूह होता है जिसमें एक समग्र status, node_id, प्रति-दस्तावेज़ परिणामों (कॉन्फ़िगर की गई फ़ील्ड कुंजी द्वारा अनुक्रमित निष्कर्षण डेटा) का एक items[] ऐरे, और warnings शामिल होते हैं।

questionnaire_responses
object[] | null

प्रश्नावली प्रतिक्रिया रिपोर्टों की ऐरे — हमेशा एक JSON ऐरे, कभी भी एकल questionnaire ऑब्जेक्ट नहीं। तब तक null जब तक कम से कम एक प्रश्नावली चरण ने डेटा उत्पन्न न किया हो। प्रत्येक आइटम पूर्ण रिपोर्ट है, जिसमें node_id, प्रश्नावली मेटाडेटा, फ़ॉर्म तत्वों वाले अनुभाग, और उपयोगकर्ता के उत्तर शामिल हैं।

bank_verifications
object[] | null

उपयोगकर्ता और व्यवसाय सत्यापन के लिए, प्रति बैंक सत्यापन चरण एक आइटम के साथ बैंक सत्यापन परिणाम। जब तक कोई चरण परिणाम नहीं देता, तब तक null। प्रत्येक आइटम की method बताती है कि खाते का सत्यापन कैसे किया गया था: open_banking (बैंक साइन-इन) या account_lookup (खाता जाँच), या statement अथवा microdeposits फ़ॉलबैक, और none जब किसी प्रयास का मूल्यांकन होने से पहले व्यक्ति बैंक के बिना आगे बढ़ गया (continued_without_bank)। देखें बैंक सत्यापन विधियाँ।

signatures
object[]

उपयोगकर्ता और व्यवसाय सत्यापन के लिए प्रति हस्ताक्षरकर्ता और हस्ताक्षर चरण एक आइटम के साथ ई-हस्ताक्षर परिणाम। केवल तभी मौजूद होता है जब वर्कफ़्लो में ई-हस्ताक्षर चरण हो; हस्ताक्षरकर्ता के उस चरण तक पहुँचने तक एक खाली ऐरे। ई-हस्ताक्षर रिपोर्ट देखें।

aml_screenings
object[] | null

AML स्क्रीनिंग रिपोर्टों की ऐरे — हमेशा एक JSON ऐरे, कभी भी एकल aml ऑब्जेक्ट नहीं। तब तक null जब तक कम से कम एक AML चरण ने डेटा तैयार न किया हो। प्रत्येक आइटम पूरी रिपोर्ट है, जिसमें node_id, फ़ीचर-स्तरीय status, total_hits, entity_type, hits[], score, screened_data, is_ongoing_monitoring_enabled, और warnings[] शामिल हैं।

ip_analyses
object[] | null

डिवाइस और IP विश्लेषण रिपोर्टों की ऐरे — हमेशा एक JSON ऐरे, कभी भी एकल ip_analysis ऑब्जेक्ट नहीं। तब तक null जब तक कम से कम एक IP-विश्लेषण चरण ने डेटा उत्पन्न न किया हो। प्रत्येक आइटम पूर्ण रिपोर्ट है, जिसमें node_id, सुविधा-स्तरीय status, IP और जियोलोकेशन डेटा, डिवाइस फ़िंगरप्रिंट, और warnings[] शामिल हैं। डुप्लिकेट (node_id, ip_address, device_fingerprint) वाली प्रविष्टियों को सर्वर-साइड पर डिडुप्लिकेट किया जाता है।

geolocation_checks
object[] | null

स्थान सत्यापन परिणामों का Array, प्रति स्थान सत्यापन चरण एक: उस चरण का स्वीकृत प्रयास। तब तक null जब तक कि किसी स्थान सत्यापन चरण ने डेटा उत्पन्न न किया हो। उसी चरण के पिछले प्रयास geolocation_attempts में हैं।

geolocation_attempts
object[] | null

इस सत्र के प्रत्येक स्थान सत्यापन चरण का प्रत्येक प्रयास, सबसे पुराना पहले। पुनः सबमिशन द्वारा प्रतिस्थापित किए गए प्रयासों को छोड़ दिया गया है। एक वर्कफ़्लो जो अपनी रिस्पॉन्स विशेषताओं के माध्यम से geolocation_checks को रोकता है, वह इस सूची को भी रोकता है।

database_validations
object[] | null

डेटाबेस सत्यापन रिपोर्टों की Array — हमेशा एक JSON array, कभी भी एकल database_validation ऑब्जेक्ट नहीं। null जब तक कि कम से कम एक DB सत्यापन चरण ने डेटा जनरेट न किया हो। प्रत्येक आइटम पूर्ण रिपोर्ट है, जिसमें node_id, सुविधा-स्तरीय status, screened_data, प्रति-सेवा validations[] (प्रत्येक अपने रजिस्ट्री source_data के साथ), और warnings[] शामिल हैं। screened_data और source_data फ़ील्ड देश के अनुसार भिन्न होते हैं:

ARG (अर्जेंटीना): screened_data: {document_number, selfie, gender, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, date_of_death, tax_id, tax_id_type, face_match_score, sit_1_since, banks, last_position, highest_position, rejected_checks}। RENAPER बायोमेट्रिक चेहरा मिलान सत्यापन का उपयोग करता है। दस्तावेज़ में मौजूद न होने पर (उदा. ड्राइविंग लाइसेंस) लिंग का स्वचालित रूप से चेहरे के विश्लेषण या दिए गए नाम से अनुमान लगाया जाता है

BOL (बोलीविया): screened_data: {document_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, gender}

BRA (ब्राज़ील): screened_data: {tax_number, first_name, last_name, date_of_birth}. सफल CPF मिलानों के लिए source_data में हमेशा {identification_number, first_name, last_name, date_of_birth, lgpd_minor, minor_under_18, minor_under_16} शामिल होता है। सफल वयस्क लुकअप उन फ़्लैग्स को false पर सेट करते हैं। Receita Federal Consulta CPF सेवा LGPD-रोके गए डेटा के साथ HTTP 422 (18 वर्ष से कम उम्र का नाबालिग) या 451 (16 वर्ष से कम उम्र) लौटा सकती है; ऐसे मामलों में source_data नाबालिग फ़्लैग्स को आवश्यकतानुसार true पर सेट करता है, अपस्ट्रीम HTTP स्थिति शामिल करता है, और फ़ील्ड-स्तरीय सत्यापन no_match होता है। पूर्ण कोड सूची के लिए डेटाबेस सत्यापन परिणाम कोड संदर्भ का ब्राज़ील अनुभाग देखें।

CHL (चिली): screened_data: {personal_number, first_name, last_name, date_of_birth}. source_data: {identification_number, first_name, last_name, date_of_birth, gender}

COL (कोलंबिया): screened_data: {document_number, document_type, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, document_type}

CRI (कोस्टा रिका): screened_data: {personal_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

DOM (डोमिनिकन गणराज्य): screened_data: {personal_number}. source_data: {identification_number} (केवल valid/invalid लौटाता है)

ECU (इक्वाडोर): screened_data: {personal_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, street, formatted_address, gender, nationality, education, marital_status, spouse, mother_name, father_name, profession}

ESP (स्पेन): screened_data: {personal_number, document_type, expiration_date, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, document_type, expiration_date}

GTM (ग्वाटेमाला): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

HND (होंडुरास): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

MEX (मेक्सिको): screened_data: {personal_number (CURP), first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, gender, nationality, curp_status, state_of_birth, doc_probatorio, registration_year, registration_state, registration_municipality, num_acta, crip, issuing_state_code, foreign_registry_number, folio_carta, folio_certificado}। RENAPO सिविल रजिस्ट्री का उपयोग करता है। एक अतिरिक्त एक-एक करके सत्यापन के रूप में MEX के लिए एक अलग INE वैधता-जाँच सेवा भी उपलब्ध है।

PAN (पनामा): screened_data: {personal_number, selfie}. source_data: {identification_number}। SIB बायोमेट्रिक सत्यापन का उपयोग करता है

PER (पेरू): screened_data: {personal_number (DNI), first_name, last_name}. source_data: {identification_number, first_name, last_name, paternal_name, maternal_name, verification_number, verification_letter}

PRY (पैराग्वे): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

SLV (अल सल्वाडोर): screened_data: {document_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

URY (उरुग्वे): screened_data: {personal_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

VEN (वेनेजुएला): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, gender, date_of_birth, document_type}

database_validation_not_performed_reason
object | null

एक कॉन्फ़िगर किए गए डेटाबेस सत्यापन ने कोई परिणाम क्यों नहीं दिया, {code, message} और संदर्भ फ़ील्ड के रूप में। केवल तभी मौजूद होता है जब उस चरण वाले वर्कफ़्लो के लिए database_validations, null हो, ताकि आप "रजिस्ट्री सहमत थी" को "कुछ नहीं चला" से अलग पहचान सकें। अन्यथा null।

reviews
object[]
assignee
object | null

कंसोल समीक्षक जिसे सत्र सौंपा गया है, या null जब इसे कोई नहीं संभाल रहा हो।

waiting_since
string<date-time> | null

सत्र समीक्षा की प्रतीक्षा कब करने लगा। null जब तक कि सत्र In Review में न हो और आपका एप्लिकेशन समीक्षा समय-सीमा निर्धारित करे।

sla_due_at
string<date-time> | null

समीक्षा कब नियत है। null जब तक कि सत्र In Review में न हो और आपका एप्लिकेशन समीक्षा समय-सीमा निर्धारित न करे।

created_at
string<date-time>

सत्र बनाए जाने का टाइमस्टैम्प (ISO 8601, UTC)।

expires_at
string<date-time> | null

वह टाइमस्टैम्प जब इस सत्र की समय-सीमा समाप्त होने का शेड्यूल है। उपयोगकर्ता सत्यापन (KYC) सत्रों पर तब सेट किया जाता है जब निर्माण के समय समाप्ति कॉन्फ़िगर की गई हो (या जब Approved स्थिति KYC समाप्ति गणना को ट्रिगर करती है)। बिना कॉन्फ़िगर की गई समाप्ति वाले सत्रों के लिए, और उन प्रकारों के लिए जो समाप्ति का उपयोग नहीं करते हैं (उदा. व्यवसाय सत्यापन (KYB) सत्र जिन्हें कभी expires_at प्राप्त नहीं हुआ) null।

registry_checks
object[] | null

कंपनी रजिस्ट्री जांच। केवल तभी मौजूद होती है जब session_kind = business हो। प्रत्येक आइटम संपूर्ण कंपनी-रजिस्ट्री payload को समेटे रहता है।

key_people_checks
object[] | null

प्रमुख व्यक्तियों की जाँच का समग्र परिणाम। केवल तभी उपस्थित होता है जब session_kind = business हो। प्रत्येक आइटम दो-बकेट संरचना (registry, submitted, ubo_kyc_summary) का उपयोग करता है।

document_verifications
object[] | null

वर्कफ़्लो नोड के अनुसार समूहीकृत दस्तावेज़ सत्यापन जाँचें। केवल तब मौजूद होती हैं जब session_kind = business हो।

environment
enum<string>

क्या सत्र किसी लाइव एप्लिकेशन (live) या सैंडबॉक्स एप्लिकेशन (sandbox) द्वारा बनाया गया था। सैंडबॉक्स सत्र निःशुल्क और पूरी तरह से सिम्युलेटेड होते हैं, और इनसे कभी भी क्रेडिट का शुल्क नहीं लिया जाता है।

उपलब्ध विकल्प:
live,
sandbox
sandbox_scenario
string | null

वह सैंडबॉक्स परिदृश्य जिसके साथ सत्र बनाया गया था। लाइव सत्रों के लिए और बिना किसी परिदृश्य के बनाए गए सैंडबॉक्स सत्रों के लिए null।

resubmissions
object[]

उपयोगकर्ता और व्यवसाय सत्रों के लिए केवल include=resubmissions के साथ लौटाया जाता है। प्रति पुनः सबमिशन अनुरोध पर एक प्रविष्टि, सबसे पुरानी पहले। प्रत्येक प्रविष्टि उन परिणामों को ले जाती है जो पुनः सबमिट किए गए चरणों ने अनुरोध से पहले लौटाए थे, ताकि पहले के सबमिशन पढ़े जा सकें। सत्र को हटाने से प्रत्येक सबमिशन डिलीट हो जाता है।

क्या सत्र को फ़ेस कैप्चर से पहले स्पष्ट बायोमेट्रिक सहमति की आवश्यकता थी, क्यों, और उत्तर का साक्ष्य। केवल उपयोगकर्ता सत्यापन (KYC) सत्र; वही ऑब्जेक्ट सत्र webhooks के decision में होता है। null जब सत्र का कभी मूल्यांकन नहीं किया गया, उदाहरण के लिए बिना फ़ेस कैप्चर वाला वर्कफ़्लो। बिना किसी रिकॉर्ड किए गए मान वाले फ़ील्ड null होते हैं। 4.10.0 से नीचे का एक नेटिव SDK, या जो अपने संस्करण की रिपोर्ट नहीं करता है, सहमति चरण नहीं दिखा सकता है: इसके फ़ेस कैप्चर पहले की तरह चलते हैं, और जिस सत्र में सहमति की आवश्यकता थी वह फिर reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK" के साथ status: "pending" रिपोर्ट करता है। देखें बायोमेट्रिक सहमति।

investigator
object | null

आइटम की नवीनतम Investigator समीक्षा, या जब इसकी कभी कोई समीक्षा नहीं हुई हो तो null। V3 सत्र और व्यावसायिक सत्र के निर्णय (और इसलिए status.updated webhooks) द्वारा वहन किए जाते हैं।

biometric_retention
object

इस सत्र का लाइव बायोमेट्रिक डेटा कब हटाया जाता है।

fraud_check
object | null

एक Fraud Check API कॉल का परिणाम। हर दूसरे सत्र के लिए null।

full_session_video
string<uri> | null

पूर्ण-सत्र रिकॉर्डिंग का समाप्त होने वाला URL। केवल तभी लौटाया जाता है जब आपका संगठन पूर्ण-सत्र वीडियो रिकॉर्ड करता है।

full_session_video_recorded_at
string<date-time> | null

जब पूर्ण-सत्र रिकॉर्डिंग की गई थी। केवल तब लौटाया जाता है जब आपका संगठन पूर्ण-सत्र वीडियो रिकॉर्ड करता है।

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