Webhook Tester
Webhook टेस्टर एक अस्थायी सार्वजनिक पता होता है जो उसे भेजे गए हर HTTP अनुरोध को रिकॉर्ड करता है, ताकि आप ठीक-ठीक देख सकें कि Webhook भेजने वाले ने वास्तव में क्या डिलीवर किया। नीचे एक हुक बनाएं और आपको एक अनूठा URL मिलेगा जो 30 मिनट तक जीवित रहता है: Stripe, GitHub, किसी भुगतान प्रदाता, किसी निगरानी सेवा या अपने कोड को उस पर इंगित करें, घटना को ट्रिगर करें, और हर डिलीवरी यहाँ आएगी—मेथड, पाथ और क्वेरी, हेडर, बॉडी और स्रोत पता—ताकि आप असली हैंडलर को जोड़ने से पहले उसकी जांच कर सकें।
अंतिम अपडेट:
आपका अस्थायी प्राप्ति URL — Webhook यहाँ भेजें
क्लिपबोर्ड पर कॉपी हो गया।
·
चेतावनी: जिसके पास भी यह URL है वह उस पर अनुरोध भेज सकता है और वह जो कुछ कैप्चर करता है उसे पढ़ भी सकता है—इसे बिल्कुल पासवर्ड की तरह समझें। इसे कभी सार्वजनिक रूप से साझा न करें, और रहस्यों या व्यक्तिगत डेटा वाले उत्पादन ट्रैफ़िक को इस पर इंगित न करें। हुक और उसके सभी कैप्चर 30 मिनट बाद अपने आप हट जाते हैं।
कैप्चर किए गए अनुरोध
अभी कोई अनुरोध नहीं। ऊपर दिए URL पर एक परीक्षण डिलीवरी भेजें—यह पेज हर 3 सेकंड में नई आगमनों की जांच करता है और उन्हें यहाँ सबसे नए पहले दिखाता है।
हुक हटा दिया गया। URL अब अनुरोध स्वीकार नहीं करता और उसने जो कुछ कैप्चर किया था वह सब चला गया।
यह सेवा क्या संग्रहीत करती है — और क्या कभी नहीं करती
हुक बनाने पर SysOSX चेकर सर्वर पर केवल हुक id, उसके बनने और समाप्ति का समय और उसे बनाने वाला पता संग्रहीत होता है। हर कैप्चर किया गया अनुरोध उसके आने का समय, मेथड, क्वेरी स्ट्रिंग सहित पाथ, ठीक जैसे भेजे गए हेडर, अधिकतम 256 KB तक की बॉडी (उससे लंबी बॉडी काट दी जाती है और चिह्नित की जाती है) और भेजने वाले का पता संग्रहीत करता है। एक हुक अधिकतम 50 अनुरोध रखता है; उसके बाद की डिलीवरी समाप्ति तक अस्वीकार कर दी जाती हैं। सब कुछ हुक बनने के 30 मिनट बाद हट जाता है, या जब आप हटाएं बटन दबाते हैं तो तुरंत हट जाता है। रिसीवर केवल प्राप्त करता है: यह कभी कुछ लाता नहीं, किसी का पीछा नहीं करता और कुछ दोहराता नहीं—कैप्चर किया गया अनुरोध किसी आउटबाउंड कॉल को ट्रिगर नहीं करता। पड़ोसी डीबगिंग टूल के लिए HTTP स्टेटस चेन ट्रेसर देखें, और पूरे वर्कफ़्लो के लिए प्लंबिंग के बिना Webhook डीबग करें पढ़ें।
रिसीवर के बिना Webhook डीबग करना क्यों अटपटा है
Webhook किसी और के सर्वर द्वारा आपके सर्वर को, उनके समय-सारणी पर, किसी ऐसी घटना की प्रतिक्रिया में बुलाया जाना है जिसे आप नियंत्रित नहीं करते—भुगतान का सफल होना, पुश का आना, अलर्ट का बजना। यही आकार Webhook को डीबग करना कष्टदायक बनाता है। भेजने वाला आपके लैपटॉप तक नहीं पहुँच सकता, इसलिए स्थानीय विकास को एक असली डिलीवरी देखने से पहले ही सुरंग या सार्वजनिक स्टेजिंग मशीन की ज़रूरत होती है; घटना को दूसरी बार ट्रिगर करना कठिन हो सकता है, इसलिए जो एकमात्र डिलीवरी आपको मिले उसे पूरी तरह कैप्चर होना चाहिए; और जब कुछ विफल होता है, तो भेजने वाले का डैशबोर्ड आमतौर पर केवल वह स्टेटस कोड दिखाता है जो आपके एंडपॉइंट ने लौटाया, यह नहीं कि उसने वास्तव में क्या भेजा। क्या सिग्नेचर हेडर मौजूद था? क्या बॉडी दस्तावेज़ों द्वारा वादा किया गया JSON आकार था, या फ़ॉर्म-एन्कोडेड था? क्या पुनः प्रयास ने वही घटना id भेजा? इनमें से किसी भी सवाल का जवाब केवल आपके हैंडलर के लॉग से नहीं मिल सकता यदि आपके हैंडलर ने अनुरोध को लॉग करने से पहले ही अस्वीकार कर दिया हो—और सिग्नेचर तथा पार्सिंग बग के साथ ठीक यही होता है, जो Webhook डीबगिंग पर हावी हैं।
एक अस्थायी रिसीवर उस चक्र से प्लंबिंग हटा देता है। क्या आता है यह देखने के लिए आधा लिखा हैंडलर तैनात करने के बजाय, आप एक ऐसा पता बनाते हैं जो सब कुछ स्वीकार करता है, उसे ईमानदारी से रिकॉर्ड करता है और आपको दिखाता है: हेडर उसी क्रम और केसिंग में जिसमें वे आए, किसी भी पार्सर को उसे अस्वीकार करने का मौका मिलने से पहले की कच्ची बॉडी, वह क्वेरी स्ट्रिंग जिसमें भेजने वाले कभी-कभी पैरामीटर छिपाते हैं, और ठीक-ठीक मेथड—क्योंकि कुछ प्रदाता POST से, कुछ PUT से डिलीवर करते हैं, और कुछ GET से स्वास्थ्य जांच करते हैं। स्क्रीन पर एक असली कैप्चर की गई डिलीवरी के साथ आप दस्तावेज़ों के बजाय सच्चाई के आधार पर अपना हैंडलर लिख सकते हैं, वास्तविक पेलोड से अपने परीक्षणों के लिए फ़िक्स्चर बना सकते हैं, और विफल पुनः प्रयास की मूल से साथ-साथ तुलना कर सकते हैं। फिर हुक हटाएं, प्रदाता को अपने असली एंडपॉइंट पर इंगित करें, और घटना को एक बार फिर ट्रिगर करके अपने हैंडलर को उसका जवाब देते देखें। तीस मिनट जानबूझकर छोटा है: डीबगिंग सत्र के लिए पर्याप्त लंबा, और इतना छोटा कि कैप्चर किए पेलोड से भरा भूला हुआ परीक्षण पता इंटरनेट पर पड़ा न रहे।
अक्सर पूछे जाने वाले प्रश्न
एक हुक कितने समय तक रहता है और कितना कैप्चर कर सकता है?
एक हुक बनने के क्षण से 30 मिनट तक रहता है, फिर हुक और उसने जो कुछ कैप्चर किया वह अपने आप हट जाता है। यह अधिकतम 50 अनुरोध रखता है; उससे अधिक की डिलीवरी हुक की समाप्ति तक 429 प्रतिक्रिया से अस्वीकार कर दी जाती हैं। हर अनुरोध बॉडी अधिकतम 256 KB तक संग्रहीत होती है—उससे लंबी बॉडी काट दी जाती है और कैप्चर को कटा हुआ चिह्नित किया जाता है ताकि आपको पता चले कि आप सब कुछ नहीं देख रहे हैं।
मेरे हुक ने जो कैप्चर किया उसे कौन देख सकता है?
जिसके पास भी हुक URL है। URL में मौजूद id ही एकमात्र प्रमाण है: यह अनुरोध भेजने और कैप्चर पढ़ने दोनों को अधिकृत करता है, उसके ऊपर कोई खाता और कोई पासवर्ड नहीं। यही इस टूल को तुरंत उपयोग योग्य बनाता है, और यही कारण है कि आपको URL को पासवर्ड की तरह समझना चाहिए—इसे सार्वजनिक रूप से पोस्ट न करें, और रहस्यों या व्यक्तिगत डेटा वाले उत्पादन ट्रैफ़िक को इस तरह के साझा व्यूअर पर कभी इंगित न करें।
क्या रिसीवर भेजने वाले को जवाब देता है, लिंक का पीछा करता है या अनुरोध दोहराता है?
नहीं। रिसीवर हर स्वीकृत डिलीवरी का जवाब एक छोटे 200 JSON अभिस्वीकृति से देता है कि वह आ गई, और उसके साथ और कुछ नहीं करता: यह पेलोड में मिले URL कभी नहीं लाता, रीडायरेक्ट का पीछा कभी नहीं करता, और कोई रीप्ले या फ़ॉरवर्डिंग नहीं देता। प्राप्त करना और जांच करना ही पूरी सेवा है, जो कैप्चर किए गए पेलोड को आउटबाउंड ट्रैफ़िक में बदलने से रोकता है।
मैं इसके साथ किन भेजने वालों का परीक्षण कर सकता हूँ?
कुछ भी जो किसी सार्वजनिक URL पर HTTP अनुरोध भेज सके: Stripe, GitHub, Shopify, भुगतान और फ़ॉर्म प्रदाता, निगरानी और CI सेवाएँ, कोई IoT उपकरण, या curl के साथ आपका अपना कोड। हुक बनाएं, URL को प्रदाता की Webhook सेटिंग (या अपनी स्क्रिप्ट) में चिपकाएं, घटना को ट्रिगर करें, और देखें कि डिलीवरी कुछ ही सेकंड में यहाँ आती है। बाद में प्रदाता से परीक्षण URL हटाना या उसे अपने असली हैंडलर पर इंगित करना याद रखें।