जब कोई webhook कभी नहीं पहुंचता

इसे क्रम में देखें - delivery log, event का नाम, firewall, और signature। Deliveries टैब तुरंत बता देता है कि Didit ने भेजा भी था या नहीं, जिससे समस्या आधी हो जाती है।

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

#Step 1: क्या Didit ने इसे भेजने की कोशिश की?

API & Webhooks में destination खोलें और Deliveries टैब देखें। हर कोशिश अलग से लॉग होती है, उसके response के साथ।

1234

1. Last sent बताता है कि Didit ने कोशिश की भी थी या नहीं।
2. View stats उस destination के लिए कोशिशें और असफलताएं दिखाता है।
3. एक test delivery आपके endpoint को event से अलग करके देखती है।
4. जो destination लगातार असफल हो रहा है उसे ठीक करते वक्त disable किया जा सकता है।

यह एक जांच समस्या को आधे में बांट देती है:

• कोई कोशिश लॉग नहीं है → उस destination के लिए event कभी generate ही नहीं हुआ। Step 2 पर जाएं।
• कोशिश लॉग है, असफल रही → Didit ने इसे भेजा और आपकी तरफ ने इसे अस्वीकार किया या पाया ही नहीं। Step 3 पर जाएं।
• कोशिश लॉग है, 2xx → यह सफलतापूर्वक deliver हो गया। समस्या delivery में नहीं, आपके handler के अंदर है।

#Step 2: कोई कोशिश लॉग नहीं हुई

संभावना के क्रम में:

1. Event subscribe नहीं है। कोई wildcard नहीं है - हर event family को साफ़-साफ़ list करना पड़ता है। और जो नाम मौजूद ही नहीं है (session.status.updated, kyc.completed) उस पर चुपचाप कुछ भी नहीं मिलता। event की लिस्ट से मिलाकर देखें।
2. गलत application। Destinations किसी application के अंतर्गत होते हैं। अगर आपके sessions किसी और application के अंतर्गत चलते हैं, तो कोई event उस destination तक कभी नहीं पहुंचेगा। सब कुछ सही तरीके से configured दिखने के बावजूद यह सबसे आम कारण है।
3. वाकई कुछ बदला ही नहीं। Webhooks बदलाव पर fire होते हैं। कोई session जो आगे नहीं बढ़ा, या कोई AML monitoring re-screen जिसे threshold से ऊपर कुछ नहीं मिला, सही तरीके से कोई event नहीं देता।
4. जिस status का आप इंतज़ार कर रहे हैं वह अभी हुआ ही नहीं। In Progress पर मौजूद session अभी खत्म नहीं हुआ। देखें जब session कभी खत्म नहीं होता।

#Step 3: delivery की कोशिश हुई और असफल रही

404 का मतलब है कि request किसी ऐसी जगह पहुंची जिसके पास आपका route नहीं था। जांचें:

• सही path, trailing slash समेत। कोई framework जो /hook को /hook/ पर redirect करता है, वह काम कर रहे endpoint को 404 या खोई हुई body में बदल सकता है।
• क्या URL सार्वजनिक है। कोई local या staging host जो internet से पहुंच योग्य नहीं है, इस तरह से fail होता है।
• क्या आपकी app के आगे कोई proxy, load balancer, या path-based router उस path को कहीं और भेज रहा है।

5xx का मतलब है कि आपका handler crash हुआ। Parse करने से पहले raw body लॉग करें ताकि आप देख सकें उसे असल में क्या मिला।

Timeout का मतलब है कि आपने काफ़ी तेज़ी से जवाब नहीं दिया। पहले 2xx लौटाएं, प्रोसेसिंग बाद में करें।

कुछ भी नहीं / connection refused का मतलब है कि आपके edge ने इसे block कर दिया। Didit static IP 18.203.201.92 से DiditWebhook/2.0 user agent के साथ deliver करता है। अगर आप Cloudflare या किसी default-deny WAF के पीछे हैं, तो receiving hostname के लिए वह IP allow करें।

#आम मामला: automatic delivery 404 देता है लेकिन Resend काम करता है

यह इतनी बार होता है कि इसे नाम देना पड़ा। Automated delivery 404 के साथ असफल हो जाती है, फिर उसी event पर Resend क्लिक करने से वह सफल हो जाता है।

इसका मतलब है कि payload और आपका endpoint, दोनों सही हैं - तो फर्क content का नहीं, timing या path का है। जांचें:

• असली delivery के समय हुआ कोई deploy या restart। बाद में Resend सफल होता है क्योंकि तब तक app फिर से चालू हो चुकी होती है।
• कोई cold start जो आपके platform के timeout से ज़्यादा समय ले गया - serverless पर धीमी पहली invocation के साथ आम है।
• दोनों कोशिशों के बीच बदल गया path-based routing, या कोई rule जो सिर्फ कुछ requests से मेल खाता है।
• आपके edge पर rate limiting या bot protection जिसने manual resend को इसलिए जाने दिया क्योंकि वह अकेला आया, किसी burst में नहीं।

Deliveries टैब में दोनों कोशिशें अपने timestamps के साथ मौजूद हैं - उन्हें उस मिनट के अपने deploy और error logs से मिलाकर देखें।

#Signature verification असफल होना

लगभग हमेशा इनमें से एक:

1. आपने re-serialised JSON hash किया। Raw request body bytes को ठीक वैसे ही HMAC करें जैसे मिले थे। Parse करके फिर से string बनाना whitespace और key order बदल देता है, और signature मेल नहीं खाएगा। ज़्यादातर frameworks को raw body देने के लिए साफ़ configuration चाहिए होती है।
2. गलत secret। Signing secret प्रति destination होता है, और यह आपकी API key नहीं है। दो destinations के दो अलग-अलग secrets होते हैं।
3. गलत encoding मान लेना। अगर आपको यकीन नहीं है कि secret को literal string की तरह इस्तेमाल किया जाए या पहले decode किया जाए, तो अंदाज़ा न लगाएं - signature verification की reference को ठीक-ठीक follow करें, और debug करते समय raw body लॉग करें ताकि आप तुलना कर सकें।

#दो retries कोई queue नहीं है

5xx, 404, timeout, या connection failure पर Didit दो बार retry करता है - लगभग 1 मिनट और फिर 4 मिनट बाद - और फिर delivery छोड़ देता है। अगर आपका endpoint इससे ज़्यादा देर तक down रहा, तो वे events हमेशा के लिए चले जाते हैं।

एक reconciliation path बनाएं: startup पर, ऐसे किसी भी session के लिए decision endpoint को poll करें जिसके लिए आपके पास कोई terminal status नहीं है। Webhooks को तेज़ रास्ता मानें और polling को backstop।

#बिना कोई verification चलाए टेस्ट करना

Destination पेज पर Try Webhook, आपके चुने हुए किसी भी तरह का पूरी तरह बना हुआ event भेजता है - approved, declined, in review, KYB, entity, transaction। इससे किसी असली session पर निर्भर होने से पहले अपने endpoint, signature check, और handler को साबित करें।

Sandbox इसका दूसरा हिस्सा है: कोई sandbox session "environment": "sandbox" के साथ असली webhooks भेजता है, इसलिए आप पूरे path को मुफ़्त में end to end आज़मा सकते हैं। देखें sandbox में टेस्ट करना।