मुख्य सामग्री पर जाएं
सत्र Didit पर सत्यापन की इकाई होते हैं। जब आप सत्यापन शुरू करते हैं, तो एक सत्र बनता है; जब सत्यापन पूरा हो जाता है, तो सत्र में पूरा निर्णय payload होता है। यही सत्र API दोनों प्रकारों को संभालती है: Didit Academy के उस पाठ में, जिसमें बताया गया है कि उपयोगकर्ता क्या देखते हैं, 5:34 वाला अध्याय होस्टेड फ़्लो की तुलना अपनी स्क्रीन बनाने से करता है। यही वह ट्रेड-ऑफ़ है जिसका निर्णय यह API आपके लिए लेती है।

​
प्रकार वर्कफ़्लो तय करता है

जब आप सत्र बनाते हैं, तो आप workflow_id पास करते हैं। वर्कफ़्लो का प्रकार तय करता है कि सत्र उपयोगकर्ता सत्यापन होगा या व्यवसाय सत्यापन; कॉलर इसे अलग से नहीं चुनते। KYB वर्कफ़्लो व्यवसाय सत्यापन सत्र बनाते हैं; KYC वर्कफ़्लो उपयोगकर्ता सत्यापन सत्र बनाते हैं।

​
session_kind डिस्क्रिमिनेटर

सत्र बनाने, प्राप्त करने, सूचीबद्ध करने, स्थिति अपडेट करने, साझा करने और इंपोर्ट करने से मिलने वाली हर प्रतिक्रिया में एक टॉप-लेवल फ़ील्ड शामिल होता है:
  • "user": सत्र उपयोगकर्ता सत्यापन (KYC) सत्र है। प्रतिक्रिया में उपयोगकर्ता-विशिष्ट सुविधा ऐरे होते हैं।
  • "business": सत्र व्यवसाय सत्यापन (KYB) सत्र है। प्रतिक्रिया में व्यवसाय-विशिष्ट सुविधा ऐरे होते हैं।
अपनी तरफ़ से प्रतिक्रिया के ढाँचे के आधार पर स्विच करने के लिए इस फ़ील्ड का उपयोग करें।
Enum मान छोटे पहचानकर्ता "user" और "business" हैं। हमने API की सुविधा के लिए इन्हें छोटा रखा है। पूरे नाम उपयोगकर्ता सत्यापन (KYC) और व्यवसाय सत्यापन (KYB) पूरे दस्तावेज़ में स्पष्टता के लिए इस्तेमाल होते हैं।

​
प्रकार के अनुसार सुविधा ऐरे

किसी निर्णय में मौजूद सुविधा ऐरे प्रकार पर निर्भर करते हैं। जो फ़ील्ड एक प्रकार में नहीं होते, वे उस प्रकार की प्रतिक्रिया में दिखाई ही नहीं देते (कोई null नहीं, कोई placeholder नहीं):

​
साझा शीर्ष-स्तरीय फ़ील्ड

हर सत्र (दोनों प्रकार) में ये फ़ील्ड होते हैं:

​
कवर किए गए endpoints

निम्नलिखित endpoints दोनों प्रकार स्वीकार करते हैं। कोई अलग /v3/business-session/* path नहीं है।

​
खोज कैसे काम करती है

उपयोगकर्ता सत्यापन और व्यवसाय सत्यापन सत्र दो अलग प्रकार हैं। IDs UUID होते हैं, इसलिए टकराव असंभव है। जब आप session_id के साथ किसी endpoint को कॉल करते हैं, तो Didit:
  1. पहले उपयोगकर्ता सत्यापन तालिका में ID खोजता है (अधिकांश ट्रैफ़िक यहीं आता है)।
  2. न मिलने पर व्यवसाय सत्यापन तालिका में खोजता है।
  3. अगर दोनों में से किसी तालिका में मिलान नहीं है, तो 404 लौटाता है।
आपको API को यह बताने की ज़रूरत नहीं होती कि आप कौन-सा प्रकार खोज रहे हैं।

​
स्थितियाँ दोनों प्रकारों में एक जैसी हैं

स्थिति मान दोनों प्रकारों के लिए एक जैसे हैं, और API उन्हें यहाँ लिखे गए रूप में ही लौटाता है: "Not Started", "In Progress", "Approved", "Declined", "In Review", "Abandoned", "Expired", "Kyc Expired", "Resubmitted", "Awaiting User"। मिलान सटीक और केस-संवेदी है। पूरी सूची के लिए सत्यापन स्थितियाँ देखें।

​
webhook

webhook इवेंट में पहले से session_kind फ़ील्ड होता है, ताकि आपके webhook हैंडलर प्रकार के अनुसार इवेंट रूट कर सकें: हस्ताक्षर सत्यापन और पुनः प्रयास के नियमों के लिए webhook देखें, और व्यवसाय सत्यापन (KYB) इवेंट सूची के लिए KYB webhook देखें।

​
अगले चरण

सत्र बनाएँ

सत्यापन शुरू करें: उपयोगकर्ता सत्यापन या व्यवसाय सत्यापन (KYB)।

सत्र प्राप्त करें

निर्णय प्राप्त करें। यह दोनों प्रकारों के लिए काम करता है।

सत्र सूची

session_kind के आधार पर फ़िल्टर करें।

स्थिति अपडेट करें

स्वीकृत करें, अस्वीकृत करें, समीक्षा करें, दोबारा सबमिट करें।

PDF जनरेट करें

प्रकार के अनुसार PDF रिपोर्ट।

शेयर + इंपोर्ट

सत्रों को एप्लिकेशन के बीच ले जाएँ।
अंतिम संशोधन 7 नवंबर 2026