गंतव्य सेट करें
आप अलर्ट webhook Business Console में कॉन्फ़िगर करते हैं, API के माध्यम से नहीं। जो सदस्य संगठन सेटिंग्स प्रबंधित कर सकते हैं, वे गंतव्य जोड़ सकते हैं, बदल सकते हैं और उनका परीक्षण कर सकते हैं।1
गंतव्य जोड़ें
संगठन सेटिंग्स > टीम की सूचनाएँ में, अपने endpoint के URL के साथ अलर्ट webhook गंतव्य जोड़ें।
URL में
https:// होना चाहिए और वह एक सार्वजनिक पते पर रिज़ॉल्व होना चाहिए।2
साइनिंग सीक्रेट सहेजें
Didit पूरा साइनिंग सीक्रेट दिखाता है, जो
whsec_ से शुरू होता है, केवल एक बार।
इसे अभी सहेज लें: उसके बाद कंसोल केवल इसके अंतिम चार अक्षर दिखाता है।3
अलर्ट को रूट करें
गंतव्य जोड़ने से अभी उस पर कुछ नहीं भेजा जाता।
जिन अलर्ट को आप इस गंतव्य पर प्राप्त करना चाहते हैं, उनके रूटिंग नियमों में गंतव्य जोड़ें।
4
परीक्षण भेजें
alert.test अलर्ट भेजने के लिए परीक्षण भेजें पर क्लिक करें, और जाँचें कि आपका endpoint उसे स्वीकार करता है।अलर्ट के प्रकार
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जुड़ते हैं।statusalert.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रिस्पॉन्स गंतव्य को फिर से कनेक्ट करने के लिए चिह्नित कर देता है (देखें पुनः प्रयास)।
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 अपडेट करते हैं, तब वह फिर से सक्रिय हो जाता है।
टीम की सूचनाएँ में हाल की सूचनाएँ हर डिलीवरी को उसके परिणाम के साथ सूचीबद्ध करती हैं, और आप वहाँ से विफल डिलीवरी का पुनः प्रयास कर सकते हैं।
संबंधित
- सत्यापन webhooks: आपके एप्लिकेशन के लिए सत्र, इकाई और लेन-देन के परिणाम।
- सेवा स्थिति: सार्वजनिक फ़ीड जिस पर
alert.service.degradedऔरalert.service.recoveredआधारित हैं। - मैन्युअल समीक्षा: समीक्षाधीन सत्यापन के साथ क्या करना है।