मुख्य सामग्री पर जाएं
सर्वर SDK आपके बैकएंड के लिए Didit की आधिकारिक लाइब्रेरी हैं। इनमें से हर एक API reference के सर्वर endpoints को टाइप्ड अनुरोधों और रिस्पॉन्सों के साथ कॉल करता है, Didit द्वारा आपको भेजे गए webhooks को सत्यापित करता है, और Didit Authentication के token जाँचता है। 1.0.1 रिलीज़ में अभी दोनों Google Wallet endpoints नहीं हैं: Google Wallet सत्यापन शुरू करें और वॉलेट रिस्पॉन्स सबमिट करें। Python, Node.js, Java, PHP, Ruby और .NET SDK में बाकी सभी सर्वर endpoints हैं। Go 1.0.1 में नौ और endpoints नहीं हैं, जिनमें से ज़्यादातर Travel Rule endpoints हैं: देखें Go SDK में अभी मौजूद नहीं endpoint। इन्हें वहाँ इस्तेमाल करें जहाँ आपके कोड में Didit API कुंजी हो: verification सत्र बनाना, निर्णय पढ़ना, standalone APIs कॉल करना, उपयोगकर्ताओं, व्यवसायों, वर्कफ़्लो और केस को मैनेज करना, लेन-देन और वॉलेट की स्क्रीनिंग करना, और Travel Rule। ब्राउज़र या मोबाइल ऐप में इसके बजाय web और native SDK का उपयोग करें: ये आपके उपयोगकर्ता को verification flow दिखाते हैं और कभी आपकी API कुंजी नहीं रखते। API reference के सर्वर endpoint pages, जिनमें Database Validation सेवा के pages भी शामिल हैं, cURL request के साथ हर सर्वर SDK का code sample दिखाते हैं। कोई sample तभी दिखाया जाता है जब किसी SDK के नवीनतम रिलीज़ में वह endpoint और वे सभी फ़ील्ड हों जो sample भेजता है: API में जोड़ा गया कोई endpoint या फ़ील्ड हर SDK के अगले रिलीज़ के साथ अपने samples पाता है। 1.0.1 रिलीज़ में Database Validation के 16 अनुरोध फ़ील्ड नहीं हैं जो जनरेट होने के बाद जोड़े गए, जैसे vin या bank_account_number, इसलिए जो service pages इन्हें भेजते हैं वे सिर्फ cURL दिखाते हैं।

​
इंस्टॉल करें

​
कॉन्फ़िगर करें

हर SDK एक ही एनवायरनमेंट वेरिएबल पढ़ता है, इसलिए बिना किसी विकल्प के बनाया गया क्लाइंट तुरंत इस्तेमाल के लिए तैयार रहता है। Edge runtimes में कोई प्रोसेस एनवायरनमेंट नहीं होता: वहाँ API कुंजी को Node.js क्लाइंट में एक विकल्प के रूप में पास करें। एनवायरनमेंट से जो कुछ भी सेट किया जा सकता है, वह क्लाइंट को भी पास किया जा सकता है, साथ ही base URL, टाइमआउट, पुनः प्रयास, डिफ़ॉल्ट हेडर और आपका अपना HTTP क्लाइंट। हर प्रोसेस के लिए एक क्लाइंट बनाएँ और उसे साझा करें: उसमें एक कनेक्शन पूल रहता है, और वह कई threads या tasks से इस्तेमाल करने के लिए सुरक्षित है। account मेथड (प्रोग्रामैटिक रजिस्ट्रेशन: रजिस्टर, साइन इन, संगठनों और एप्लिकेशन) https://apx.didit.me/auth/v2 को कॉल करते हैं और आपकी API कुंजी कभी नहीं भेजते। account.login से साइन इन करें, फिर लौटाया गया access token क्लाइंट को उसके account token के रूप में पास करें।

​
हर SDK क्या करता है

  • Resources और methods। कॉल API के resources का पालन करते हैं: client.<resource>.<method>(...), उदाहरण के लिए sessions.create, sessions.retrieve_decision या transactions.create, हर भाषा की अपनी नामकरण शैली में। Path ids positional arguments हैं; body और query फ़ील्ड्स का एक ही नामित सेट हैं। Python, Node.js, PHP और Ruby API के अपने field names (workflow_id) इस्तेमाल करते हैं; Go, Java और .NET अपनी भाषा की नामकरण शैली (WorkflowID, workflowId, WorkflowId) इस्तेमाल करते हैं।
  • सूचियाँ। List methods आपके लिए हर परिणाम तक पेजिनेशन करते हैं (नीचे limit और offset के साथ), और हर पेज को count, next, previous और results के साथ भी उपलब्ध कराते हैं। Ruby में auto_paging_each हर पेज तक जाता है, और किसी पेज के total_count, next_url और previous_url API के count, next और previous हैं।
  • फ़ाइलें। अपलोड (दस्तावेज़ की छवियाँ, सेल्फ़ी, पते का प्रमाण, इंपोर्ट) path, bytes या stream स्वीकार करते हैं। डाउनलोड (सत्र PDF, reports) bytes या stream लौटाते हैं, कभी पार्स किया हुआ JSON नहीं।
  • फ़ॉरवर्ड कंपैटिबिलिटी। SDK के जिस वर्ज़न को कोई रिस्पॉन्स फ़ील्ड या enum value अभी पता नहीं है, वह सुरक्षित रखा जाता है और पढ़ा जा सकता है, कभी error नहीं होता, ताकि API में जोड़ा गया कोई बदलाव तैनात integration को न तोड़े।
  • Webhooks। webhooks.verify आपके webhook सीक्रेट से किसी डिलीवरी के X-Signature-V2 और X-Signature हेडर और उसके टाइमस्टैम्प की जाँच करता है, और एक typed event लौटाता है। रोटेट करते समय यह सीक्रेट्स की सूची भी स्वीकार करता है। हस्ताक्षर की योजना के लिए देखें Webhooks।
  • Authentication। एक Authentication हेल्पर उन access और ID tokens को सत्यापित करता है जिन्हें आपका Authentication issuer साइन करता है, और उसके token, सत्र और step-up endpoints को कॉल करता है। यह कभी आपकी API कुंजी इस्तेमाल नहीं करता।

​
त्रुटियाँ, पुनः प्रयास और टाइमआउट

हर त्रुटि DiditError से व्युत्पन्न होती है। Go में हर त्रुटि didit.Error इंटरफ़ेस लागू करती है और *didit.NotFoundError जैसे पॉइंटर प्रकार की होती है। Java, PHP और .NET में इन्हें उनके सामान्य Exception सफ़िक्स के साथ नाम दिया जाता है, और API को Api लिखा जाता है: DiditException, ApiStatusException, NotFoundException। SDK विफल अनुरोध को अधिकतम 2 बार पुनः प्रयास करते हैं, 0.5 सेकंड से शुरू होने वाले घातीय बैकऑफ़ के साथ (पूर्ण जिटर, अधिकतम 8 सेकंड), और Retry-After हेडर का सम्मान करते हुए। GET, HEAD, PUT और DELETE का पुनः प्रयास कनेक्शन त्रुटियों, टाइमआउट, 408, 429 और 5xx पर होता है। POST और PATCH का पुनः प्रयास केवल 429 पर होता है, या तब जब अनुरोध भेजे जाने से पहले कनेक्शन विफल हुआ हो, ताकि पुनः प्रयास से दूसरा सत्र या लेन-देन न बने। डिफ़ॉल्ट टाइमआउट 60 सेकंड है। हर प्रतिक्रिया कच्चा HTTP स्टेटस, हेडर और अनुरोध ID भी देती है। 429 के पीछे की सीमाओं के लिए रेट लिमिट देखें।

​
वर्ज़निंग और सहायता

  • SDK सिमेंटिक वर्ज़निंग का पालन करते हैं, जिसमें API बदलावों के लिए एक नियम है। जो बदलाव Didit API को दर्शाता है, वह माइनर रिलीज़ होता है, भले ही वह टाइप्ड कोड तोड़ सकता हो (किसी फ़ील्ड का प्रकार बदलना, किसी फ़ील्ड का अब null हो सकना, या किसी endpoint, फ़ील्ड या enum मान का हटना)। API पहले से हर कॉलर के लिए ऐसे ही व्यवहार करता है, इसलिए पुराना SDK वर्ज़न सुरक्षित नहीं है। रिलीज़ नोट्स ऐसे बदलावों को “टाइप्ड कोड तोड़ सकने वाले API बदलाव” के अंतर्गत सूचीबद्ध करते हैं।
  • मेजर वर्ज़न केवल SDK के अपने डिज़ाइन में बदलाव के लिए होता है: ऐसा मेथड या रिसोर्स जिसका नाम बदला गया या हटाया गया, जबकि API उसे रखता है; क्लाइंट कॉन्फ़िगरेशन, त्रुटियों, पुनः प्रयासों, पेजिनेशन या webhook सत्यापन के व्यवहार में बदलाव; या रनटाइम वर्ज़न का समर्थन बंद होना। जब कोई endpoint API से हटता है या किसी मेथड का नाम बदलता है, तो पुराना मेथड कम से कम एक और माइनर वर्ज़न तक पदावनत चिह्नित होकर रहता है, ताकि नए मेथड पर जाते समय आपका कोड चलता रहे। हर भाषा का अपना वर्ज़न नंबर है: Node.js, PHP और Ruby 2.x पर हैं और बाकी 1.x पर, क्योंकि इन तीनों ने इस नियम के लागू होने से पहले एक API बदलाव को मेजर वर्ज़न के रूप में जारी किया था।
  • ये प्रकाशित API अनुबंध (openapi-25.json और openapi-auth.json) से बनाए जाते हैं, और इनके Didit Authentication मेथड openapi-authentication.json के विरुद्ध जाँचे जाते हैं। इन तीनों की रोज़ जाँच होती है, इसलिए कोई नया endpoint या फ़ील्ड सातों SDK की नियमित रिलीज़ में आ जाता है।
  • हर SDK तालिका में दिया गया न्यूनतम रनटाइम और उससे नए हर रिलीज़ का समर्थन करता है। उसके टेस्ट न्यूनतम रनटाइम और हर नए रिलीज़ पर चलते हैं, या Node.js और Java के लिए हर दीर्घकालिक समर्थन (LTS) रिलीज़ पर।
  • हर रिपॉज़िटरी की CHANGELOG.md हर रिलीज़ के बदलाव सूचीबद्ध करती है।
  • किसी सुरक्षा समस्या की रिपोर्ट SDK रिपॉज़िटरी की सुरक्षा एडवाइज़री के माध्यम से या support@didit.me पर निजी तौर पर करें।
अंतिम संशोधन 7 नवंबर 2026