वेबहुक क्या है? ऐप्स एक-दूसरे को कैसे सूचित करते हैं

वेबहुक एक स्वचालित संदेश है जो एक सेवा आपके ऐप को तब भेजती है जब कुछ होता है। जब किसी ग्राहक का पेमेंट सफल होता है, तो Stripe आपके ऐप के एक पते पर वेबहुक भेजता है जिसमें लिखा होता है "पेमेंट सफल, विवरण यह रहे", और आपका ऐप प्रतिक्रिया देता है — ऑर्डर को paid मार्क करता है, रसीद भेजता है, अकाउंट खोलता है। संक्षेप में: API में आपका ऐप दूसरी सेवा से सवाल पूछता है; वेबहुक में दूसरी सेवा आपके ऐप को कुछ बताने के लिए कॉल करती है।

AI से बनाते समय यह क्यों मायने रखता है

जैसे ही आपका ऐप पेमेंट लेता है, किसी दूसरे टूल से फ़ॉर्म सबमिशन लेता है, या GitHub, Shopify या कैलेंडर जैसी सेवाओं से जुड़ता है, आप वेबहुक से टकराएँगे। ये अक्सर यह जानने का सही तरीका होते हैं कि कुछ हुआ है — लेकिन AI से बने ऐप में यहीं सबसे ज़्यादा बारीक गलतियाँ होती हैं:

• एंडपॉइंट कोई भी request स्वीकार करता है, तो कोई भी नकली "पेमेंट सफल" event भेज सकता है।
• ऐप चेकआउट के redirect वाले पेज पर एक्सेस देता है, न कि वेबहुक पर, तो जो लोग टैब जल्दी बंद कर देते हैं उन्हें वह नहीं मिलता जिसके लिए उन्होंने पैसे दिए, और जो सफलता वाला URL ढूँढ लेते हैं उन्हें मुफ़्त मिल जाता है।
• वही event दो बार आता है और ग्राहक को दो ऑर्डर या दो ईमेल मिलते हैं।

वेबहुक कैसे काम करते हैं यह जानने से आप शुरू में ही इन सुरक्षाओं की माँग कर सकते हैं।

रोज़मर्रा की मिसाल: डिलीवरी का मैसेज

आप दो तरह से जान सकते हैं कि आपका पार्सल पहुँचा या नहीं। आप हर दस मिनट में दरवाज़े तक जाकर देख सकते हैं (इसे polling कहते हैं — आपका ऐप बार-बार API को कॉल करके पूछता है "कुछ नया है?")। या कूरियर डिलीवरी होने पर आपको मैसेज भेज सकता है (यह वेबहुक है)।

मैसेज साफ़ तौर पर बेहतर है — बशर्ते आप उस पर भरोसा कर सकें। अगर कोई भी आपको "पार्सल पहुँचा" का मैसेज भेज सकता, तो आप जानना चाहेंगे कि वह सच में कूरियर से आया है। और अगर मैसेज आने के समय आपका फ़ोन बंद था, तो आप चाहेंगे कि कूरियर बाद में फिर कोशिश करे। ये दो बातें — verification और retries — वेबहुक को मुश्किल बनाने वाली ज़्यादातर बातें हैं।

वेबहुक कैसे काम करता है, चरण-दर-चरण

1. आप अपने ऐप के बैकएंड में एक एंडपॉइंट बनाते हैं: एक URL, जैसे https://yourapp.com/webhooks/stripe, जो POST requests स्वीकार करे।
2. आप वह URL प्रोवाइडर के साथ रजिस्टर करते हैं और चुनते हैं कि कौन से events चाहिए (जैसे "checkout पूरा हुआ" और "subscription रद्द")।
3. प्रोवाइडर आपको एक signing secret देता है। उसे आप अपने सर्वर पर एक secret के रूप में सेव करते हैं — देखें environment variables और secrets।
4. कोई event होता है। प्रोवाइडर आपके URL पर एक HTTP request भेजता है, जिसमें JSON body में उसका विवरण और एक signature header होता है।
5. आपका ऐप signature verify करता है, event ID रिकॉर्ड करता है, तुरंत सफलता कोड (200) लौटाता है, और फिर काम करता है।
6. अगर आपका ऐप सफलता का जवाब नहीं देता, तो कई प्रोवाइडर बाद में फिर कोशिश करते हैं।

Signatures

Signature साबित करता है कि request प्रोवाइडर से आई है और बदली नहीं गई। उदाहरण के लिए Stripe, signing secret का इस्तेमाल करके request body और एक timestamp पर SHA-256 के साथ HMAC (एक तरह का keyed fingerprint) बनाता है, और उसे Stripe-Signature header में भेजता है। आपका ऐप अपनी secret की कॉपी से वही गणना करता है; नतीजे मेल खाएँ तो request असली है। चूँकि timestamp भी signed होता है, आप उन पुरानी requests को ठुकरा सकते हैं जिन्हें कोई रिकॉर्ड करके बाद में दोबारा भेजे — Stripe के libraries सितंबर 2026 तक के उसके documentation के अनुसार डिफ़ॉल्ट रूप से पाँच मिनट की सहनशीलता रखते हैं।

एक व्यावहारिक बात: signature raw request body पर बनता है। अगर आपका framework verify करने से पहले JSON को parse करके दोबारा format कर देता है, तो जाँच फेल हो जाती है। यह एक बहुत आम बग है।

Retries, दोहराव और क्रम

प्रोवाइडर अलग-अलग हैं, इसलिए हर एक का documentation देखें। सितंबर 2026 तक:

Stripe का documentation यह भी कहता है कि events की गारंटी नहीं कि वे उसी क्रम में आएँगे जिसमें हुए, और यही event कभी-कभी एक से ज़्यादा बार आ सकता है, इसलिए वह event IDs ट्रैक करने की सलाह देता है।

सामान्य सबक हर प्रोवाइडर पर लागू होता है: events देर से, एक से ज़्यादा बार और गलत क्रम में आ सकते हैं। आपका handler idempotent होना चाहिए — उसी event को दो बार प्रोसेस करने का वही असर हो जो एक बार का होता है।

एक उदाहरण: पेड कोर्स अनलॉक करना

आप एक ऑनलाइन कोर्स बेचते हैं। एक छात्र Buy पर क्लिक करता है, Stripe के होस्टेड चेकआउट पेज पर पैसे देता है, और आपकी साइट पर वापस भेजा जाता है।

नाज़ुक तरीका: "धन्यवाद" पेज कोर्स अनलॉक कर देता है। अगर छात्र redirect के दौरान ब्राउज़र बंद कर दे, तो उसने पैसे दिए पर उसे एक्सेस नहीं मिला। और अगर कोई thank-you URL का अंदाज़ा लगा ले, तो उसे बिना पैसे दिए एक्सेस मिल जाता है।

वेबहुक वाला तरीका:

1. जब Stripe पेमेंट की पुष्टि करता है, तो वह /webhooks/stripe पर checkout.session.completed event भेजता है।
2. आपका बैकएंड signing secret से signature verify करता है। अगर वह फेल हो, तो 400 लौटाता है और कुछ नहीं करता।
3. यह जाँचता है कि वह event ID पहले प्रोसेस हो चुका है या नहीं। अगर हाँ, तो 200 लौटाकर रुक जाता है।
4. event ID सेव करता है, 200 लौटाता है, और फिर छात्र को एक्सेस देता है और स्वागत का ईमेल भेजता है।
5. thank-you पेज बस कहता है "पेमेंट मिल गया — आपका कोर्स थोड़ी देर में दिखेगा" और छात्र का एक्सेस स्टेटस जाँचता है।

बाद में, अगर कोई subscription रद्द हो या कार्ड फेल हो, तो दूसरे वेबहुक events आपके ऐप को एक्सेस हटाने या रोकने के लिए कहते हैं। इसी तरह subscription वाले प्रोडक्ट बिलिंग के साथ सिंक में रहते हैं — देखें SaaS क्या है और अपने ऐप में पेमेंट कैसे जोड़ें।

मुख्य शब्द

• Endpoint: आपके ऐप का URL जो वेबहुक लेता है।
• Event / payload: क्या हुआ, और उसका विवरण देने वाला डेटा (आम तौर पर JSON)।
• Signing secret: signatures verify करने के लिए साझा किया गया secret।
• Idempotent: एक ही परिणाम के साथ एक से ज़्यादा बार चलाना सुरक्षित।
• Polling: बदलाव का इंतज़ार करने की बजाय बार-बार API से बदलाव पूछना।
• Tunnel: एक टूल जो लैपटॉप को विकास के दौरान अस्थायी सार्वजनिक URL देता है, ताकि वेबहुक वहाँ पहुँच सकें।

आम गलतियाँ और गलतफ़हमियाँ

• signatures verify न करना। Endpoint का URL कोई secret नहीं है। Verification ही request को भरोसेमंद बनाता है।
• जवाब देने से पहले धीमा काम करना। जवाब से पहले ईमेल भेजना या PDF बनाना timeouts ला सकता है, जिससे retries होते हैं, और retries से दोहराव।
• एक बार, क्रम से आने की उम्मीद। Event IDs रिकॉर्ड करें और आगमन के क्रम पर निर्भर न रहें।
• प्रिव्यू URL इस्तेमाल करना। वेबहुक को एक स्थिर, सार्वजनिक पता चाहिए। निजी प्रिव्यू और localhost इंटरनेट से नहीं पहुँचते; अपना publish किया गया URL इस्तेमाल करें (या टेस्ट के दौरान tunnel)।
• टेस्ट और लाइव secrets मिलाना। प्रोवाइडर अक्सर टेस्ट और लाइव मोड के लिए अलग signing secrets देते हैं। दोनों सेव करें और सही वाला इस्तेमाल करें।
• महत्वपूर्ण फ़ैसलों में payload पर आँख मूँदकर भरोसा। ज़रूरी कार्रवाइयों के लिए event मिलने के बाद प्रोवाइडर के API से ताज़ा स्थिति लाना समझदारी है।

अपने AI बिल्डर से क्या माँगें

सर्वर पर एक POST /webhooks/stripe एंडपॉइंट जोड़ो। raw request body और secret STRIPE_WEBHOOK_SECRET से Stripe signature verify करो। गलत signatures को 400 से ठुकराओ। हर event ID सेव करो और पहले से प्रोसेस हुए events को छोड़ दो। जल्दी 200 लौटाओ, फिर checkout.session.completed पर ऑर्डर को paid मार्क करो और रसीद भेजो। event type लॉग करो। Checkout के सफलता पेज से एक्सेस मत दो।

फिर उसे टेस्ट करें: प्रोवाइडर के डैशबोर्ड से एक टेस्ट event भेजें, वही दोबारा भेजें, और गलत signature वाली request भेजें। सिर्फ़ पहली से कुछ बदलना चाहिए।

Mythex पर वेबहुक

Mythex का अलग वेबहुक सर्विस नहीं है; आप एजेंट से अपने ऐप के अपने बैकएंड में वेबहुक एंडपॉइंट जोड़ने को कहते हैं, और प्रोवाइडर को अपना publish किया गया URL देते हैं, क्योंकि वेबहुक को सार्वजनिक पता चाहिए। signing secret आपके प्रोजेक्ट secrets में जाता है, और अगर लाइव ऐप पर उसे बदलें, तो फिर से publish करें। वेबहुक संभालना वाली docs रेसिपी में एक स्टार्टर प्रॉम्प्ट है, और पेमेंट लेने वाले ऐप्स के लिए स्टोर टेम्पलेट एक अच्छा शुरुआती बिंदु हैं।

सवाल