मुख्य सामग्री पर जाएं
अलर्ट webhook आपकी टीम के अलर्ट आपके स्वामित्व वाले HTTPS endpoint पर भेजते हैं। इनका उपयोग ऑन-कॉल टूल, टिकट कतार या अपने संचालन डैशबोर्ड को डेटा देने के लिए करें। अलर्ट webhook सत्यापन webhook से अलग हैं। सत्यापन webhook आपके एप्लिकेशन को सत्र, इकाई और लेन-देन के परिणाम भेजते हैं। अलर्ट webhook आपकी टीम को बताते हैं कि किसी चीज़ पर ध्यान देने की ज़रूरत है: समीक्षा की प्रतीक्षा कर रहा सत्यापन, विफल भुगतान, या सेवा में कोई घटना। इनके अपने payload, साइनिंग सीक्रेट, हस्ताक्षर और पुनः प्रयास का शेड्यूल होते हैं।

गंतव्य सेट करें

आप अलर्ट webhook Business Console में कॉन्फ़िगर करते हैं, API के माध्यम से नहीं। जो सदस्य संगठन सेटिंग्स प्रबंधित कर सकते हैं, वे गंतव्य जोड़ सकते हैं, बदल सकते हैं और उनका परीक्षण कर सकते हैं।
1

गंतव्य जोड़ें

संगठन सेटिंग्स > टीम की सूचनाएँ में, अपने endpoint के URL के साथ अलर्ट webhook गंतव्य जोड़ें। URL में https:// होना चाहिए और वह एक सार्वजनिक पते पर रिज़ॉल्व होना चाहिए।
2

साइनिंग सीक्रेट सहेजें

Didit पूरा साइनिंग सीक्रेट दिखाता है, जो whsec_ से शुरू होता है, केवल एक बार। इसे अभी सहेज लें: उसके बाद कंसोल केवल इसके अंतिम चार अक्षर दिखाता है।
3

अलर्ट को रूट करें

गंतव्य जोड़ने से अभी उस पर कुछ नहीं भेजा जाता। जिन अलर्ट को आप इस गंतव्य पर प्राप्त करना चाहते हैं, उनके रूटिंग नियमों में गंतव्य जोड़ें।
4

परीक्षण भेजें

alert.test अलर्ट भेजने के लिए परीक्षण भेजें पर क्लिक करें, और जाँचें कि आपका endpoint उसे स्वीकार करता है।
किसी संगठन की टीम की सूचनाएँ में अधिकतम 25 गंतव्य हो सकते हैं। केवल लाइव गतिविधि ही किसी गंतव्य तक पहुँचती है। सैंडबॉक्स सत्यापन, व्यवसाय सत्यापन, लेन-देन और AML हिट के बारे में अलर्ट उसे कभी नहीं भेजे जाते।

अलर्ट के प्रकार

Payload

हर अलर्ट एक JSON बॉडी के साथ POST होता है। Didit बॉडी को संक्षिप्त JSON के रूप में भेजता है, जिसकी कुंजियाँ क्रमबद्ध हैं। यह उदाहरण पढ़ने के लिए फ़ॉर्मैट किया गया है:
data में हमेशा ये होते हैं:
  • event: इवेंट कुंजी, उदाहरण के लिए session_in_review।
  • label और value: जिसके बारे में अलर्ट है, उदाहरण के लिए Session और #1042।
कुछ अलर्ट प्रकार data में कुंजियाँ जोड़ते हैं:
  • alert.billing.autorefill_failed में paused जुड़ता है, एक बूलियन मान, जो true होता है जब ऑटो-रीफ़िल अब रोक दिया गया है और आपके कार्ड अपडेट करने तक रुका रहेगा।
  • alert.service.degraded और alert.service.recovered में service, status, incident_id, service_name, state, affected, country_name, started_at, resolved_at, duration_minutes, title और body जुड़ते हैं। status alert.service.degraded पर degraded या down होता है, और alert.service.recovered पर recovered। service में GET /v3/status/ की सेवा कुंजियाँ इस्तेमाल होती हैं, और incident_id वहाँ मौजूद किसी घटना के id से मेल खाता है।
अलर्ट में कभी अंतिम उपयोगकर्ता का व्यक्तिगत डेटा या दस्तावेज़ का डेटा शामिल नहीं होता। वे सत्र, लेन-देन या किसी अन्य आइटम की पहचान उसकी संख्या से करते हैं और कंसोल में उसका लिंक देते हैं। webhook_type के वे मान और data की वे कुंजियाँ अनदेखी करें जिन्हें आप पहचानते नहीं, ताकि नए मान आपके endpoint को न तोड़ें।

अनुरोध हेडर

हस्ताक्षर सत्यापित करें

X-Signature-V2 उस स्ट्रिंग का hex-encoded HMAC-SHA256 है जो <X-Timestamp>.<raw body> है, और इसे आपके गंतव्य के हस्ताक्षर सीक्रेट से साइन किया जाता है।
  • Didit ने जैसा दिखाया था, पूरा सीक्रेट ठीक वैसे ही इस्तेमाल करें, जिसमें whsec_ प्रिफ़िक्स भी शामिल हो।
  • कच्चे अनुरोध के बाइट्स को वैसे ही साइन करें जैसे आपको मिले थे। JSON को parse करके फिर से serialize करने से बाइट्स बदल सकते हैं और जाँच विफल हो सकती है।
  • हस्ताक्षरों की तुलना constant time में करें।
  • ऐसे अनुरोध को अस्वीकार करें जिसका X-Timestamp आपकी घड़ी से 5 मिनट से ज़्यादा दूर हो। Didit हर प्रयास पर, हर पुनः प्रयास सहित, नया टाइमस्टैम्प लगाकर साइन करता है, इसलिए यह विंडो कभी भी वास्तविक पुनः प्रयास को अस्वीकार नहीं करती।
  • विफल जाँच का उत्तर 400 से दें। 401, 403, 404 या 410 रिस्पॉन्स गंतव्य को फिर से कनेक्ट करने के लिए चिह्नित कर देता है (देखें पुनः प्रयास)।
अलर्ट webhook को सत्यापन webhook की तरह साइन नहीं किया जाता। Header का नाम भी X-Signature-V2 ही है, लेकिन साइन की गई स्ट्रिंग अलग है, और अलर्ट webhook कोई X-Signature या X-Signature-Simple नहीं भेजते। अपने सत्यापन webhook सत्यापक को दोबारा इस्तेमाल न करें।

Node.js (Express)

Python (Flask)

हस्ताक्षर सीक्रेट बदलें

आप टीम की सूचनाएँ में गंतव्य का सीक्रेट बदलते हैं। Didit नया सीक्रेट एक बार दिखाता है और उसके बाद हर प्रयास को उसी से साइन करता है, जिसमें बदलाव से पहले बनाए गए अलर्ट के पुनः प्रयास भी शामिल हैं। पुराना सीक्रेट तुरंत काम करना बंद कर देता है। इसमें कोई ओवरलैप अवधि नहीं है, और कोई header पिछले सीक्रेट से बने हस्ताक्षर नहीं भेजता। सीक्रेट बदलते ही नया सीक्रेट अपने endpoint पर तैनात कर दें।

पुनः प्रयास

Didit किसी भी 2xx रिस्पॉन्स को डिलीवर हुआ मानता है। हर प्रयास आपके रिस्पॉन्स के लिए अधिकतम 5 सेकंड प्रतीक्षा करता है और रीडायरेक्ट का पालन नहीं करता। Didit टाइमआउट, कनेक्शन विफलता, 5xx रिस्पॉन्स, या 408, 425 या 429 रिस्पॉन्स के बाद अलर्ट का पुनः प्रयास करता है। यह अधिकतम 5 बार, लगभग 24 घंटे की अवधि में पुनः प्रयास करता है: बाकी हर रिस्पॉन्स अंतिम होता है, जिसमें 3xx और कोई भी अन्य 4xx शामिल है। परीक्षण भेजें से भेजा गया परीक्षण केवल एक प्रयास किया जाता है और उसका कभी पुनः प्रयास नहीं होता। 401, 403, 404 या 410 रिस्पॉन्स भी गंतव्य को फिर से कनेक्ट करने के लिए चिह्नित कर देता है: कंसोल उसे फिर से कनेक्ट करें स्थिति के साथ दिखाता है। Didit जब भेजता है, तब यदि कोई URL किसी निजी या अन्यथा अवरुद्ध पते पर रिज़ॉल्व होता है, तो भी यही होता है। Didit गंतव्य पर नए अलर्ट भेजता रहता है, और अगली सफल डिलीवरी के बाद या जब आप उसका URL अपडेट करते हैं, तब वह फिर से सक्रिय हो जाता है। टीम की सूचनाएँ में हाल की सूचनाएँ हर डिलीवरी को उसके परिणाम के साथ सूचीबद्ध करती हैं, और आप वहाँ से विफल डिलीवरी का पुनः प्रयास कर सकते हैं।

संबंधित

अंतिम संशोधन 7 नवंबर 2026