Webhook एंडपॉइंट चेकर

सर्वर सहायता नया वेब यूटिलिटीज़

वह URL डालें जिस पर webhook आने चाहिए और Mutqan सर्वर उसे एक तय JSON टेस्ट बॉडी (type "mutqan.webhook_check", एक रैंडम id और जाँच का समय) वाली एक POST और एक OPTIONS रिक्वेस्ट भेजता है, फिर बताता है कि webhook भेजने वाले को क्या मिलेगा: स्टेटस कोड, जवाब का समय, सादा HTTP, redirect (दिखाया जाता है, फ़ॉलो नहीं होता), छूटे हेडर और जवाब के पहले 2,048 अक्षर। आपके लिखे में से URL के सिवा कुछ नहीं भेजा जाता, इसलिए यह जाँच कोई असली इवेंट दोबारा नहीं भेज सकती और कोई सिग्नेचर नहीं ले जा सकती।

गोपनीयता: Mutqan सर्वर इस पेज पर बताई गई छोटी, तय टेस्ट रिक्वेस्ट आपके बताए होस्ट को भेजता है, और कुछ भी स्टोर नहीं होता। इसे सिर्फ़ उन्हीं सिस्टम पर इस्तेमाल करें जिन्हें टेस्ट करने की आपको अनुमति है।

भरोसेमंद डिलीवरी पाने के लिए webhook एंडपॉइंट को क्या करना चाहिए?

HTTPS पर POST का जवाब जल्दी 2xx से दे — GitHub जैसे प्रोवाइडर 10 सेकंड के भीतर इसकी उम्मीद करते हैं — और वह भी ठीक दर्ज किए URL पर, क्योंकि कई भेजने वाले redirect फ़ॉलो नहीं करते और 2xx के सिवा हर जवाब को दोबारा भेजने लायक़ विफलता मानते हैं। उसे कुछ करने से पहले कच्ची बॉडी पर भेजने वाले का सिग्नेचर सत्यापित करना चाहिए, बिना साइन की रिक्वेस्ट ठुकरानी चाहिए, और असली काम पावती के बाद करना चाहिए, ताकि धीमी प्रोसेसिंग से एक ही इवेंट दोबारा न आए।

सुरक्षा नोट: Webhook URL सार्वजनिक है: जिसे भी पता चले वह उस पर पोस्ट कर सकता है। सिग्नेचर को constant-time तुलना से सत्यापित करें, पुराने टाइमस्टैम्प ठुकराएँ, और पेलोड को कभी भरोसेमंद इनपुट न मानें।

Webhook एंडपॉइंट चेकर कैसे इस्तेमाल करें

  1. वह URL डालें जो आपने webhook प्रोवाइडर के पास दर्ज किया है (या करेंगे), जैसे https://api.example.com/webhooks/incoming।
  2. "एंडपॉइंट जाँचें" दबाएँ। Mutqan सर्वर टेस्ट POST और OPTIONS रिक्वेस्ट एक-एक बार भेजता है।
  3. "Webhook भेजने वाले को क्या दिखेगा" ऊपर से पढ़ें: पहली पंक्ति बताती है कि डिलीवरी गिनी जाती या नहीं।
  4. अगर एंडपॉइंट ने बिना साइन वाले टेस्ट को 400, 401 या 403 से ठुकराया, तो साइन वाले एंडपॉइंट से यही अपेक्षित है; स्वीकार वाला रास्ता जाँचने के लिए प्रोवाइडर से साइन किया टेस्ट इवेंट भेजें।

Webhook एंडपॉइंट चेकर की खूबियाँ

  • Webhook प्रोवाइडर की तरह एक टेस्ट डिलीवरी — JSON POST — और एक OPTIONS रिक्वेस्ट भेजता है और दिखाता है कि एंडपॉइंट ने कैसे जवाब दिया
  • स्टेटस को वैसे समझाता है जैसे भेजने वाला मानेगा: डिलीवर (2xx), redirect होकर खोया, साइन किए होने से अस्वीकार (400, 401, 403), नहीं मिला, अनुमति नहीं, फ़ेल (5xx)
  • जवाब का समय नापता है और 3 सेकंड से धीमे जवाब पर चेताता है, जहाँ से भेजने वाले हार मानकर दोबारा कोशिश करने लगते हैं
  • सादा HTTP, redirect (कहाँ जाता है यह भी, फ़ॉलो किए बिना), छूटा Content-Type और Retry-After हेडर बताता है
  • Webhook के लिए ज़रूरी रिस्पॉन्स हेडर और जवाब के पहले 2,048 अक्षर टेक्स्ट के रूप में दिखाता है
  • ठीक-ठीक दिखाता है कि क्या भेजा गया: रैंडम id और समय वाली तय बॉडी, कभी आपका डेटा या कोई असली इवेंट नहीं

इनपुट और आउटपुट

इनपुट

  • Webhook URL — वह http:// या https:// पता जिस पर प्रोवाइडर डिलीवर करता है; "example.com/hook" में https:// जोड़ दिया जाता है। URL में यूज़र-नेम और पासवर्ड स्वीकार नहीं।
  • और कुछ नहीं: मेथड, हेडर और बॉडी तय हैं और बदले नहीं जा सकते।

आउटपुट

  • सारांश — POST का HTTP स्टेटस, उसमें लगा समय, URL HTTPS है या नहीं, और OPTIONS रिक्वेस्ट का स्टेटस।
  • Webhook भेजने वाले को क्या दिखेगा — हर जाँच अपने नतीजे के साथ: डिलीवरी, HTTPS, रिस्पॉन्स टाइम, Content-Type, OPTIONS का जवाब और Retry-After।
  • रिस्पॉन्स हेडर और बॉडी — webhook के लिए ज़रूरी हेडर (Content-Type, Server, Allow, Retry-After, X-Request-Id, CORS) और जवाब के पहले 2,048 अक्षर, टेक्स्ट के रूप में।
  • क्या भेजा गया और इस जाँच के बारे में — दोनों रिक्वेस्ट ठीक वैसे ही जैसे सर्वर भेजता है, और जाँच क्या नहीं बता सकती।

Webhook एंडपॉइंट चेकर का उदाहरण

साइन वाला webhook रिसीवर जो बिना साइन वाले टेस्ट को सही तरह ठुकराता है

इनपुट:

https://hooks.example.com/payments/events

आउटपुट:

सारांश: HTTP स्टेटस 401 · रिस्पॉन्स टाइम 184 ms · एन्क्रिप्टेड (HTTPS) हाँ · OPTIONS का जवाब 204
Webhook भेजने वाले को क्या दिखेगा: टेस्ट POST स्वीकार करता है — जानकारी (ठुकराया, जो सिग्नेचर या टोकन जाँचने वाले एंडपॉइंट के लिए सही है) · HTTPS — पास · रिस्पॉन्स टाइम — पास (3 सेकंड के भीतर) · जवाब का Content-Type — जानकारी · OPTIONS रिक्वेस्ट — जानकारी
रिस्पॉन्स हेडर: content-type application/json · x-request-id 7f3c9a
रिस्पॉन्स बॉडी: {"error":"invalid signature"}

Webhook एंडपॉइंट चेकर के नतीजे कैसे पढ़ें

पहली पंक्ति में पास (2xx) का मतलब है कि असली डिलीवरी भी शायद स्वीकार होगी, बशर्ते एंडपॉइंट कुछ ऐसा न जाँचे जो यह टेस्ट नहीं भेज सकता, जैसे सिग्नेचर।

400, 401 या 403 के साथ जानकारी सिग्नेचर या टोकन जाँचने वाले एंडपॉइंट का अपेक्षित जवाब है: रूट मौजूद है और अपनी रक्षा करता है। यह इस बात का सबूत नहीं कि असली इवेंट पास होंगे।

Redirect के साथ विफल का मतलब है कि डिलीवरी कहीं नहीं पहुँचती; redirect वाला URL दर्ज करें। 404 या 405 के साथ विफल का मतलब आमतौर पर ग़लत पाथ या सिर्फ़ GET स्वीकार करने वाला रूट है।

3 सेकंड से ज़्यादा रिस्पॉन्स टाइम चेतावनी है, विफलता नहीं: भेजने वाले अलग-अलग हैं, पर ज़्यादातर 5 से 10 सेकंड बाद रुककर दोबारा भेजते हैं, जिससे एक ही इवेंट दो बार पहुँच सकता है।

Webhook एंडपॉइंट चेकर कब इस्तेमाल करें

  • पेमेंट, Git या मैसेजिंग प्रोवाइडर के पास webhook URL दर्ज करने से पहले: क्या वह पहुँच में है, HTTPS है, तेज़ है और redirect नहीं करता?
  • डिप्लॉयमेंट या DNS बदलाव के बाद, जब डिलीवरी अचानक timeout या 404 से फ़ेल होने लगें।
  • पक्का करना कि साइन वाला एंडपॉइंट बिना साइन की रिक्वेस्ट को प्रोसेस करने के बजाय ठुकराता है।
  • प्रॉक्सी या API गेटवे के पीछे के रिसीवर की जाँच, जो redirect जोड़ सकता है या उसे धीमा कर सकता है।

समस्या निवारण

  • "एंडपॉइंट ने समय पर जवाब नहीं दिया": 10 सेकंड में कुछ नहीं आया। देखें कि सर्विस चल रही है और सिर्फ़ आपके नेटवर्क से नहीं, इंटरनेट से भी पहुँच में है।
  • "Webhook जाँचें हर पते के लिए 10 मिनट में 20 तक सीमित हैं": बताया गया समय रुकें; यह सीमा जाँचे जा रहे एंडपॉइंट की रक्षा करती है।
  • जवाब 403 वाला HTML पेज है: आपका ऐप्लिकेशन नहीं, कोई फ़ायरवॉल या बॉट-सुरक्षा जवाब दे रही है। प्रोवाइडर के पतों को अनुमति दें, जैसा उसके दस्तावेज़ बताते हैं।
  • टेस्ट ने आपका हैंडलर चला दिया: एंडपॉइंट बिना साइन वाला JSON स्वीकार करता है। type mutqan.webhook_check या X-Mutqan-Webhook-Check हेडर को नज़रअंदाज़ करें, और सिग्नेचर ज़रूरी करने पर विचार करें।

Webhook एंडपॉइंट चेकर के बारे में अक्सर पूछे जाने वाले सवाल

जाँच ठीक-ठीक क्या भेजती है?

बॉडी {"type":"mutqan.webhook_check","id":…,"sentAt":…} (रैंडम UUID और जाँच का समय) वाली एक POST, Content-Type: application/json, User-Agent: MutqanTools-WebhookCheck/1.0 और X-Mutqan-Webhook-Check: 1 के साथ, फिर उन्हीं दो पहचान वाले हेडर के साथ एक OPTIONS रिक्वेस्ट। Mutqan relay दोनों में X-Mutqan-Relay: 1 हेडर जोड़ता है। न सिग्नेचर, न कुकी, न URL के सिवा आपका लिखा कुछ भी; "क्या भेजा गया" दोनों रिक्वेस्ट दिखाता है।

मेरे एंडपॉइंट ने 401, 403 या 400 दिया। क्या वह ख़राब है?

शायद नहीं। भेजने वाले का सिग्नेचर या साझा टोकन जाँचने वाले एंडपॉइंट को ऐसा बिना साइन वाला टेस्ट ठुकराना ही चाहिए, और यह इनकार दिखाता है कि रूट मौजूद और सुरक्षित है। स्वीकार वाला रास्ता जाँचने के लिए प्रोवाइडर के डैशबोर्ड से साइन किया टेस्ट इवेंट भेजें, या प्रोवाइडर को Webhook टेस्टर की ओर मोड़कर देखें कि वह असल में क्या भेजता है।

Redirect को समस्या क्यों बताया जाता है?

कई webhook भेजने वाले redirect फ़ॉलो नहीं करते, और जो करते हैं वे अक्सर 301 या 302 के बाद POST को GET में बदल देते हैं, इसलिए डिलीवरी खो जाती है या बिना बॉडी के पहुँचती है। प्रोवाइडर के पास आख़िरी URL दर्ज करें।

एंडपॉइंट को कितनी जल्दी जवाब देना चाहिए?

भेजने वाले बस कुछ सेकंड रुकते हैं — जैसे GitHub 10 सेकंड के भीतर 2xx की उम्मीद करता है — फिर दोबारा कोशिश करते हैं या डिलीवरी को फ़ेल मानते हैं। तुरंत पावती दें और काम बैकग्राउंड में करें; यह जाँच 3 सेकंड से धीमे हर जवाब पर चेताती है और 10 सेकंड बाद रुक जाती है।

क्या टेस्ट मेरा बिज़नेस लॉजिक चला देगा?

चला सकता है, अगर एंडपॉइंट बिना साइन वाला JSON स्वीकार करता है। बॉडी का type, mutqan.webhook_check, कोई असली प्रोवाइडर नहीं भेजता, और हर रिक्वेस्ट में X-Mutqan-Webhook-Check: 1 होता है, ताकि आप उसे पहचानकर नज़रअंदाज़ कर सकें।

मैं कितनी जाँच कर सकता हूँ?

एक पते से हर 10 मिनट में बीस, उस प्रति-मिनट कोटे के ऊपर जो आपकी ओर से साइटों से जुड़ने वाले बाक़ी टूल्स के साथ साझा है। सीमा पूरी होने पर पेज बताता है कि कितना रुकना है।

तकनीकी नोट्स

Webhook वह HTTP POST है जो प्रोवाइडर आपके दर्ज URL पर भेजता है। भेजने वाले हर 2xx जवाब को डिलीवरी मानते हैं और बाक़ी सब — 3xx, 4xx, 5xx या timeout — को बाद में दोबारा भेजने लायक़ विफलता (स्टेटस की श्रेणियाँ RFC 9110 परिभाषित करता है)। कई redirect फ़ॉलो नहीं करते, और जो क्लाइंट करता है वह 301 या 302 के बाद POST को GET में बदल सकता है (RFC 9110 §15.4), जिससे बॉडी खो जाती है।

जाँच Mutqan सर्वर से ठीक दो रिक्वेस्ट करती है: Content-Type: application/json, User-Agent MutqanTools-WebhookCheck/1.0, X-Mutqan-Webhook-Check: 1 और बॉडी {"type":"mutqan.webhook_check","id":…,"sentAt":…} वाली POST, फिर उन्हीं दो पहचान वाले हेडर के साथ OPTIONS; relay दोनों में अपना X-Mutqan-Relay: 1 हेडर जोड़ता है। होस्ट को सिर्फ़ सार्वजनिक पतों पर resolve होना चाहिए, हर रिक्वेस्ट 10 सेकंड तक रुकती है, और redirect फ़ॉलो नहीं होते।

साइन वाले webhook कच्ची बॉडी पर HMAC या सिग्नेचर किसी हेडर में रखते हैं (HTTP Message Signatures, RFC 9421, इसका एक रूप मानकीकृत करता है)। यह टेस्ट बिना साइन का है, इसलिए सही बना रिसीवर इसे ठुकराता है; Webhook सिग्नेचर एनालाइज़र कैप्चर किया सिग्नेचर सत्यापित करने में मदद करता है।

सीमाएँ और कार्यप्रणाली

यह रिक्वेस्ट प्रॉक्सी नहीं है और असली इवेंट दोबारा नहीं भेज सकता: बॉडी, हेडर और मेथड तय हैं और कोई सिग्नेचर नहीं भेजा जाता, इसलिए सिग्नेचर जाँचने वाला एंडपॉइंट सिर्फ़ अपना इनकार दिखा सकता है।

एक डिलीवरी Mutqan सर्वर के नेटवर्क से ली गई झलक है; प्रोवाइडर अपने पतों से भेजते हैं, जिनके साथ फ़ायरवॉल अलग बर्ताव कर सकता है, और अपने समय पर दोबारा कोशिश करते हैं।

जवाब के सिर्फ़ पहले 2,048 अक्षर और कुछ हेडर दिखाए जाते हैं; जवाब देने के बाद एंडपॉइंट क्या करता है, यह नहीं दिखता।

सुरक्षा और गोपनीयता

आपके ब्राउज़र से सिर्फ़ URL जाता है। Mutqan सर्वर एंडपॉइंट को रैंडम id और समय वाली तय टेस्ट बॉडी भेजता है, कभी आपका डेटा नहीं, और कुछ सहेजता नहीं; इसे सिर्फ़ उन एंडपॉइंट पर इस्तेमाल करें जिन्हें जाँचने की आपको अनुमति है।

संदर्भ

  • Best practices for using webhooksGitHub Docsकिसी प्रोवाइडर के अपने नियम: HTTPS इस्तेमाल करें, webhook secret सत्यापित करें, 10 सेकंड के भीतर 2xx दें और प्रोसेसिंग बाद में करें, और दोबारा हुई डिलीवरी संभालें।
  • RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
  • RFC 9421: HTTP Message SignaturesIETF · 2024HTTP मैसेज पर हस्ताक्षर करने का मानक तरीका ताकि रिसीवर उनके स्रोत और अखंडता की जाँच कर सके — आधुनिक वेबहुक सिग्नेचर का आधार।