जब कोई verification status बदलता है तो Didit ईमेल नहीं करता - webhook सेट करें ताकि आपका backend उसी वक्त जान जाए, और भरोसा करने से पहले signature verify करें।
Webhook एक HTTP request है जो कुछ बदलने पर Didit आपके URL को भेजता है। API & Webhooks के अंतर्गत एक destination जोड़ें, जिन events में दिलचस्पी है उन्हें subscribe करें - कोई wildcard नहीं है, हर एक को अलग से list करें - signing secret सेव करें, और कुछ भी process करने से पहले signature verify करें।
जब कोई session In Review या Declined पर जाता है तो Didit आपको email नहीं भेजता। console को बार-बार refresh किए बिना status बदलने का पता तुरंत लगाने के लिए, एक webhook सेट करें - आपके server पर एक URL जिसे Didit अपने आप update भेजता है।
Webhooks recommended integration pattern हैं। Decision endpoint को poll करना एक fallback की तरह काम करता है, लेकिन यह धीमा है, ज़्यादा requests लेता है, और उन events को छोड़ देता है जो सिर्फ webhook से ही भेजे जाते हैं - जैसे किसी reviewer द्वारा किया गया data edit, transaction status में बदलाव, और entity-level बदलाव।
#एक सेट करना
- डेवलपर → Webhooks
सही ऐप्लिकेशन और Live या Sandbox परिवेश चुनें, फिर डेवलपर और Webhooks खोलें।
- एंडपॉइंट जोड़ें
एंडपॉइंट जोड़ें दबाएं, HTTPS URL और नाम भरें और इवेंट चुनें। पुराने इंटीग्रेशन को बनाए रखने के अलावा सुझाया v3 संस्करण रखें। जांचकर पुष्टि करें।
- Signing secret सेव करें
हर एंडपॉइंट का अपना छिपा हुआ सिग्नेचर सीक्रेट है। दिखाएं दबाकर पहचान की पुष्टि करें; यह 60 सेकंड में फिर छिप जाता है। इसे सर्वर कॉन्फ़िगरेशन में रखें। बटन बंद हो तो सहायता से संपर्क करें। डेवलपर → Webhooks.
- टेस्ट इवेंट भेजें
असली सत्यापन किए बिना एंडपॉइंट, सिग्नेचर और हैंडलर जांचने के लिए हस्ताक्षरित टेस्ट इवेंट भेजें।
#जिन events को आप subscribe कर सकते हैं
कोई wildcard नहीं है - जो भी event family चाहिए, उसे list करें। इन्हें कई destinations में बांटना ठीक है और अक्सर ज़्यादा साफ़-सुथरा भी।
| Event | कब fire होता है |
|---|---|
status.updated | किसी KYC या KYB session का status बदलता है। जो आपको लगभग निश्चित रूप से चाहिए |
data.updated | बनने के बाद verification data edit होता है - जैसे किसी reviewer द्वारा किसी field को ठीक करना |
user.status.updated | कोई consolidated user ACTIVE, FLAGGED और BLOCKED के बीच बदलता है |
user.data.updated | किसी consolidated user की profile, counters या identifiers बदलते हैं |
business.status.updated | कोई consolidated business status बदलता है |
business.data.updated | किसी consolidated business का data बदलता है |
transaction.created | एक transaction बनता है और उसका शुरुआती verdict तैयार हो जाता है |
transaction.status.updated | बाद में किसी transaction का status बदलता है |
travel_rule.status.updated | किसी Travel Rule exchange का status बदलता है |
session.status.updated या kyc.completed नाम का कोई event नहीं है। अगर आपने इस
लिस्ट में न होने वाले किसी नाम को subscribe किया है, तो आपको कुछ नहीं मिलेगा - और
यह बिल्कुल किसी delivery failure जैसा दिखेगा। पहले नाम जांच लें।
#आपके endpoint को क्या करना चाहिए
- किसी भी चीज़ से पहले signature verify करें। Raw request body को HMAC करें - parsed JSON की फिर से बनाई गई किसी version को कभी नहीं, क्योंकि दोबारा string बनाने से bytes बदल जाते हैं और signature मेल नहीं खाएगा। Constant-time comparison इस्तेमाल करें।
- तेज़ी से 2xx लौटाएं। भारी काम जवाब देने के बाद, asynchronously करें।
- Idempotent रहें। Event id पर, या session id + status + webhook type पर key करें। Retries और duplicates होते रहते हैं।
- जिस भी status की परवाह है उसे हैंडल करें, यहां तक कि जो onboarding के काफ़ी बाद आते हैं - कोई approved session बाद में ongoing AML monitoring की वजह से In Review में जा सकता है।
- सिर्फ HTTPS। Plain HTTP endpoints सपोर्टेड नहीं हैं।
#Retries
5xx या 404 जवाब पर Didit लगभग एक मिनट और फिर चार मिनट बाद दोबारा कोशिश करता है। 5 सेकंड से अधिक टाइमआउट या कनेक्शन विफलता पर अपने-आप कोशिश नहीं होती। समस्या ठीक करने के बाद डिलीवरी सूची से फिर भेजें; अंतिम विफलता पर अलर्ट मिलता है।
हर webhook पहुंचने की गारंटी न मानें। रुकावट के बाद डिलीवरी फिर भेजें या जिन सत्रों का परिणाम नहीं मिला, उनका निर्णय API से लें।
#Firewall या WAF के पीछे
Didit static IP 18.203.201.92 से DiditWebhook/2.0 user agent के साथ deliver करता है। अगर आपका edge अनजान clients को block करता है - जैसे Cloudflare का default posture - तो receiving hostname के लिए वह IP allow करें, वरना deliveries आपके कोड तक पहुंचने से पहले ही असफल हो जाएंगी।
#अभी तक कोई backend नहीं है?
आप बनाते समय भी console के Verifications section में मैन्युअल रूप से नतीजे देख सकते हैं, या तब तक no-code verification link इस्तेमाल कर सकते हैं।
#अगले कदम
- जब कोई webhook नहीं पहुंचता: जब कोई webhook कभी नहीं पहुंचता
- पहुंचने के बाद हर status का मतलब समझें: हर session status का मतलब
- पूरी technical reference, signature verification के code उदाहरणों समेत: Webhooks
अभी भी अटके हैं? किसी व्यक्ति से बात करें।
अपने संगठन की ID और जिस सेशन के बारे में पूछ रहे हैं उसकी ID शामिल करें।