Webhooks से verification के नतीजे पाना

जब कोई verification status बदलता है तो Didit आपको email नहीं करता - एक webhook सेट करें ताकि आपका backend उसी वक्त इसके बारे में जान जाए, और उस पर भरोसा करने से पहले signature verify करें।

Didit सपोर्ट द्वारा लिखित · अपडेट किया गया 19 अगस्त 2026

Short answer

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 बदलाव।

#एक सेट करना

  1. API & Webhooks पर जाएं

    Business Console में, जिस application के लिए events पाना चाहते हैं उसे खोलें, फिर API & Webhooks पर जाएं।

  2. एक destination जोड़ें

    इसे एक label, आपके endpoint का सार्वजनिक HTTPS URL दें, और जिन events में दिलचस्पी है उन्हें चुनें - कम से कम session status में बदलाव।

  3. Signing secret सेव करें

    Destination आपको secret एक बार दिखाता है। इसे सेव करें - आपका server इससे पुष्टि करता है कि request किसी नकल करने वाले की नहीं बल्कि वाकई Didit की है। पूरे verification steps: Signature verification।

  4. इसे टेस्ट करें

    उसी पेज पर Try Webhook से अपने endpoint को पूरी तरह बना हुआ test event भेजें - approved, declined, in review, KYB, entity, और transaction परिदृश्य। इस तरह आप बिना कोई असली verification चलाए अपना integration जांच सकते हैं।

Webhook destinations in the Didit console with subscribed events and delivery history
  1. Add destination वह URL रजिस्टर करता है जहां Didit नतीजे पोस्ट करता है।
  2. भरोसा करने से पहले हर delivery को इस signing secret से verify करें।
  3. चुनें कि कोई destination कौन-से events पाएगा।
  4. Test Webhook एक sample payload भेजता है ताकि आप पुष्टि कर सकें कि आपका endpoint इसे स्वीकार करता है।
हर destination के अपने subscribed events, signing secret, और delivery log होते हैं।

#जिन 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 बदलता है
Note

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, timeout, या connection failure पर, Didit दो बार retry करता है:

  • पहली retry, पहली असफलता के करीब 1 मिनट बाद
  • दूसरी retry, उसके करीब 4 मिनट बाद

उसके बाद delivery छोड़ दी जाती है। हर कोशिश destination के Deliveries टैब में अलग से लॉग होती है, ताकि आप अंदाज़ा लगाने के बजाय ठीक-ठीक देख सकें कि क्या हुआ।

Important

पांच मिनट में दो retries कोई भरोसेमंद queue नहीं है। अगर आपका endpoint एक घंटे तक down रहा, तो वे events हमेशा के लिए चले जाते हैं। Startup पर उन sessions के लिए decision endpoint को poll करके reconcile करें जिनके लिए आपके पास कोई terminal status नहीं है - webhooks तेज़ रास्ता हैं, इकलौता रास्ता नहीं।

#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 इस्तेमाल कर सकते हैं।

#अगले कदम