चरण 1: अपने क्रेडेंशियल प्राप्त करें
api_key प्राप्त करने के दो तरीके हैं:
विकल्प A: प्रोग्रामैटिक रजिस्ट्रेशन (बिना ब्राउज़र)
CI/CD और AI एजेंट्स के लिए सबसे उपयुक्त। दो API कॉल:POST /programmatic/register/ और फिर POST /programmatic/verify-email/, जो सीधे api_key लौटाती हैं।
→ पूरे प्रवाह, पासवर्ड नियमों, JWT की अवधि और लॉकआउट नीति के लिए प्रोग्रामैटिक रजिस्ट्रेशन देखें।
विकल्प B: Didit कंसोल से
- Didit कंसोल पर जाएं।
- अपना संगठन बनाएं या चुनें।
- सेटिंग्स → API और webhook पर जाएं।
- इन्हें कॉपी करें:
- API कुंजी: हर सत्यापन कॉल पर
x-api-keyहेडर के रूप में उपयोग होती है। - webhook गुप्त कुंजी: webhook के HMAC हस्ताक्षरों की पुष्टि के लिए उपयोग होती है।
- API कुंजी: हर सत्यापन कॉल पर
एनवायरनमेंट वेरिएबल
चरण 2: वर्कफ़्लो बनाएं
सत्र बनाने से पहले आपको एक पहचान सत्यापन वर्कफ़्लो चाहिए। वर्कफ़्लो तय करता है कि उपयोगकर्ता किन सत्यापन चरणों से गुजरेंगे।कंसोल में बनाएं
- Didit कंसोल पर जाएं → वर्कफ़्लो
- वर्कफ़्लो बनाएं पर क्लिक करें
- एक बेस टेम्पलेट चुनें:
- वैकल्पिक सुविधाएं जोड़ें:
- अपना वर्कफ़्लो ID कॉपी करें
विस्तृत कॉन्फ़िगरेशन विकल्पों के लिए वर्कफ़्लो दस्तावेज़ीकरण देखें।
चरण 3: सत्यापन सत्र बनाएं
अपने उपयोगकर्ता के लिए सत्र बनाने हेतु API को कॉल करें।अनुरोध
अनुरोध पैरामीटर
सभी विकल्पों वाला पूरा उदाहरण
expected_details.expected_document_types पहचान सत्यापन चरण को विशिष्ट दस्तावेज़ प्रकारों तक सीमित करता है। दस्तावेज़ चयन स्क्रीन केवल अनुरोधित प्रकार दिखाती है। अनुमत मान: P (पासपोर्ट), ID (राष्ट्रीय पहचान पत्र), DL (ड्राइविंग लाइसेंस), RP (निवास परमिट), HIC (स्वास्थ्य बीमा कार्ड), TC (टैक्स कार्ड), SSC (सामाजिक सुरक्षा कार्ड)। मान केस-इनसेंसिटिव हैं और डुप्लीकेट हटा दिए जाते हैं; अज्ञात मानों पर 400 मिलता है। पूरे स्कीमा के लिए सत्र बनाने का API संदर्भ देखें।रिस्पॉन्स
201 Created:
मुख्य रिस्पॉन्स फ़ील्ड
आइडेम्पोटेंसी. जब
vendor_data दिया गया हो और उसी vendor_data वाला कोई अधूरा सत्र (Not Started, In Progress, Resubmitted, या Awaiting User) वर्कफ़्लो के नवीनतम प्रकाशित संस्करण पर पहले से मौजूद हो, तो डुप्लीकेट बनाने के बजाय वही मौजूदा सत्र लौटाया जाता है (अब भी 201 के साथ)। इसका callback और metadata नए मानों पर अपडेट हो जाते हैं, और status मौजूदा सत्र की स्थिति दिखाता है।x-api-key के बिना अनुरोध करने पर 403 मिलता है, जिसकी बॉडी वही होती है जो वैध कुंजी पर अनुमति न होने पर मिलती है: {"detail": "You do not have permission to perform this action."}। गलत, रद्द या समाप्त कुंजी पर 401 मिलता है। अपर्याप्त क्रेडिट होने पर 400 मिलता है। पूरे दस्तावेज़ के लिए सत्र बनाने का API संदर्भ देखें।चरण 4: उपयोगकर्ता को सत्यापन दिखाएं
अपने उपयोगकर्ता को सत्यापन फ़्लो दिखाने का तरीका चुनें:विकल्प A: नेटिव SDK (मोबाइल के लिए अनुशंसित)
कैमरा, NFC और बायोमेट्रिक इंटीग्रेशन के लिए नेटिव SDKs के साथsession_token का उपयोग करें।
→ iOS SDK · Android SDK · React Native · Flutter
विकल्प B: InContext iframe (वेब के लिए अनुशंसित)
चरण 3 में मिलेurl का उपयोग करके सत्यापन को अपने पेज में एम्बेड करें।
विकल्प C: रीडायरेक्ट
उपयोगकर्ता को सत्यापन URL पर रीडायरेक्ट करें।विकल्प D: मोबाइल WebView
उन मोबाइल ऐप्स के लिए जिनमें नेटिव SDK नहीं है।चरण 5: परिणाम प्राप्त करें
Webhook के माध्यम से (अनुशंसित)
जब सत्यापन की स्थिति बदलती है, तब webhooks वास्तविक समय में आपके सर्वर को सूचित करते हैं। सेटअप:- कंसोल (API & Webhooks) में या
POST /v3/webhook/destinations/के माध्यम से,webhook_version: "v3"और एकsubscribed_eventsarray (जैसे["status.updated"]) के साथ webhook गंतव्य बनाएँ - निर्माण के समय लौटाए गए
secret_shared_keyको सुरक्षित रखें: यह सभी हस्ताक्षर रूपों के लिए HMAC सीक्रेट है - अपने सर्वर पर एक webhook endpoint लागू करें
decision के भीतर, हर फ़ीचर का परिणाम एक बहुवचन ऐरे के रूप में मिलता है (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], …), और workflow के हर नोड के लिए एक प्रविष्टि होती है। यह V3 अनुबंध है और इसमें बदलाव नहीं होता: कभी भी एकवचन nfc, id_verification या liveness कुंजी के आधार पर कोड न लिखें।
decision ऑब्जेक्ट केवल तभी मौजूद होता है जब status Approved, Declined, In Review या Abandoned हो (Resubmitted इवेंट में इसके बजाय resubmit_info होता है)। Didit एक ही event_id को पुनः प्रयासों और fan-out गंतव्यों में दोबारा इस्तेमाल करता है, इसलिए idempotency के लिए इसी फ़ील्ड पर अपनी कुंजी रखें। हर बहुवचन array और फ़ील्ड के लिए डेटा मॉडल देखें।
हस्ताक्षर सत्यापित करें (X-Signature-V2, अनुशंसित):
X-Signature-V2 JSON body के canonical re-encoding पर HMAC-SHA256 है: पूर्ण-मान वाले floats को integers में छोटा किया जाता है, keys पुनरावर्ती रूप से sort की जाती हैं, separators compact होते हैं, और Unicode सुरक्षित रखा जाता है।
X-Signature, अप्रचलित envelope-only X-Signature-Simple और कौन सा चुनें, यह भी शामिल है। Didit विफल डिलीवरी (5xx, 404, timeout) को अधिकतम 2 बार पुनः प्रयास करता है (लगभग 1 मिनट, फिर लगभग 4 मिनट बाद), और 5 सेकंड के बाद timeout हो जाता है, इसलिए 2xx तुरंत लौटाएँ।
API के माध्यम से (वैकल्पिक)
किसी भी समय वही decision payload प्राप्त करें:decision ऑब्जेक्ट के समान है, और यह endpoint सत्र के जीवनचक्र के किसी भी बिंदु पर कॉल किया जा सकता है। real-time अपडेट के लिए webhooks इस्तेमाल करें और API कॉल्स को backfill, audit और rebuilds के लिए रखें। /decision/ endpoint प्रति API कुंजी प्रति मिनट 600 GET अनुरोधों तक सीमित है (देखें रेट लिमिट)। त्रुटि व्यवहार: अज्ञात session_id पर {"detail": "Not found."} के साथ 404 लौटता है; प्रमाणीकरण विफलताएँ 403 के रूप में दिखती हैं, और यह endpoint कभी 401 नहीं लौटाता। प्रतिक्रिया में मीडिया URLs अल्पकालिक presigned links हैं, इसलिए इन्हें स्टोर करने के बजाय तुरंत प्राप्त करें।
→ सत्र प्राप्त करने का API संदर्भ
पूर्ण कोड उदाहरण
Node.js / Express
Python / FastAPI
सत्र की स्थितियाँ
येstatus के 10 संभावित मान हैं, जो बिल्कुल इसी रूप में और case-sensitive strings के रूप में लिखे जाते हैं (ध्यान दें कि Kyc Expired में केवल एक बड़ा K है):
पूरा जीवनचक्र, संक्रमण और Mermaid आरेख देखने के लिए सत्यापन स्थितियाँ देखें।
अगले चरण
- अपनी इंटीग्रेशन विधि चुनें:
- webhooks कॉन्फ़िगर करें: Webhooks
- क्षमता की योजना बनाएँ: रेट लिमिट
- हर स्थिति को संभालें: सत्यापन स्थितियाँ
- अपना वर्कफ़्लो अनुकूलित करें: वर्कफ़्लो
- जाँचें कि API पहुँच योग्य है: Healthcheck
मदद चाहिए?
- सहायता: support@didit.me
- प्रोग्रामेटिक ऑनबोर्डिंग: प्रोग्रामेटिक पंजीकरण