वेबहुक म्हणजे काय? ॲप्स एकमेकांना कशी सूचना देतात

वेबहुक हा एक स्वयंचलित संदेश आहे, जो काही घडल्या क्षणी एक सेवा तुमच्या ॲपला पाठवते. ग्राहकाचे पेमेंट यशस्वी झाले की Stripe तुमच्या ॲपमधील एका पत्त्यावर वेबहुक पाठवते, "पेमेंट यशस्वी झाले, तपशील हे आहेत" असे सांगत, आणि तुमचे ॲप त्यावर प्रतिक्रिया देते — ऑर्डर पेड म्हणून चिन्हांकित करते, पावती पाठवते, खाते उघडते. थोडक्यात: API म्हणजे तुमचे ॲप दुसऱ्या सेवेला प्रश्न विचारते; वेबहुक म्हणजे दुसरी सेवा तुमच्या ॲपला काहीतरी सांगण्यासाठी कॉल करते.

AI सह बनवताना हे का महत्त्वाचे आहे

तुमचे ॲप पेमेंट स्वीकारू लागले, दुसऱ्या टूलकडून फॉर्म सबमिशन घेऊ लागले, किंवा GitHub, Shopify किंवा कॅलेंडरसारख्या सेवांशी जोडले गेले की तुम्हाला वेबहुक भेटतील. काहीतरी घडले हे कळण्याचा ते सहसा योग्य मार्ग असतात — पण AI-बांधलेल्या ॲप्समध्ये ते सर्वाधिक वेळा सूक्ष्मपणे चुकीचे असतात:

• एंडपॉइंट कोणतीही विनंती स्वीकारतो, त्यामुळे कोणीही "पेमेंट यशस्वी" घटना बनावटपणे पाठवू शकतो.
• ॲप चेकआउट रीडायरेक्ट पानावर प्रवेश देते, वेबहुकवर नव्हे, त्यामुळे टॅब लवकर बंद करणारे लोक ज्यासाठी पैसे दिले ते मिळवत नाहीत, आणि यशाच्या URL वर पोहोचणारे लोक ते मोफत मिळवतात.
• तीच घटना दोनदा येते आणि ग्राहकाला दोन ऑर्डर किंवा दोन ईमेल मिळतात.

वेबहुक कसे काम करतात हे माहीत असेल, तर संरक्षणे आधीच मागता येतात.

दैनंदिन उदाहरण: डिलिव्हरीचा मेसेज

तुमचे पार्सल आले की नाही हे दोन मार्गांनी कळू शकते. प्रत्येक दहा मिनिटांनी दारापर्यंत जाऊन पाहू शकता (याला पोलिंग म्हणतात — तुमचे ॲप वारंवार API ला "काही नवीन आहे का?" विचारत राहते). किंवा कुरियर डिलिव्हर झाल्यावर मेसेज पाठवू शकतो (हा वेबहुक आहे).

मेसेज स्पष्टपणे चांगला आहे — जोपर्यंत तुम्ही त्यावर विश्वास ठेवू शकता. कोणीही "पार्सल पोहोचले" असा मेसेज पाठवू शकत असेल, तर तो खरोखर कुरियरकडून आला हे तपासण्याचा मार्ग हवा. आणि मेसेज आला तेव्हा तुमचा फोन बंद असेल, तर कुरियरने नंतर पुन्हा प्रयत्न करावा अशी अपेक्षा असेल. त्या दोन गोष्टी — पडताळणी आणि पुन्हा प्रयत्न — वेबहुक अवघड बनवतात.

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

1. तुम्ही एंडपॉइंट तयार करता तुमच्या ॲपच्या बॅकएंडमध्ये: https://yourapp.com/webhooks/stripe सारखा URL जो POST विनंत्या स्वीकारतो.
2. तो URL प्रदात्याकडे नोंदवता आणि हव्या असलेल्या घटना निवडता (उदा. "checkout completed" आणि "subscription cancelled").
3. प्रदाता तुम्हाला साइनिंग सिक्रेट देतो. तो तुमच्या सर्व्हरवर सिक्रेट म्हणून साठवता — एन्व्हायर्नमेंट व्हेरिएबल्स आणि सिक्रेट्स पहा.
4. घटना घडते. प्रदाता तुमच्या URL वर HTTP विनंती पाठवतो, घटनेचे वर्णन करणारे JSON बॉडी आणि सिग्नेचर हेडरसह.
5. तुमचे ॲप सिग्नेचरची पडताळणी करते, इव्हेंट ID नोंदवते, पटकन यशाचा कोड (200) परत करते, आणि मग काम करते.
6. तुमचे ॲप यशस्वी उत्तर न दिल्यास, अनेक प्रदाते नंतर पुन्हा प्रयत्न करतात.

सिग्नेचर

सिग्नेचर सिद्ध करते की विनंती प्रदात्याकडूनच आली आणि तिच्यात बदल झालेला नाही. उदाहरणार्थ Stripe, साइनिंग सिक्रेटचा वापर करून विनंती बॉडी आणि टाइमस्टॅम्पवर HMAC (एक प्रकारचा कीड फिंगरप्रिंट) SHA-256 ने मोजते आणि ते Stripe-Signature हेडरमध्ये पाठवते. तुमचे ॲप त्याच्या प्रतीच्या सिक्रेटसह तीच गणना करते; दोन्ही निकाल जुळले तर विनंती खरी आहे. टाइमस्टॅम्पवरही सिग्नेचर असल्याने, कोणी जुनी नोंदवलेली विनंती नंतर पुन्हा पाठवली तर ती नाकारता येते — Stripe च्या लायब्ररी सप्टेंबर 2026 पर्यंतच्या दस्तऐवजानुसार डीफॉल्टने पाच मिनिटांची सहनशीलता वापरतात.

एक व्यावहारिक तपशील: सिग्नेचर मूळ विनंती बॉडीवर मोजले जाते. तुमचा फ्रेमवर्क पडताळणीपूर्वी JSON पार्स करून पुन्हा फॉरमॅट करत असेल, तर तपासणी अयशस्वी होते. ही खूप सामान्य चूक आहे.

पुन्हा प्रयत्न, डुप्लिकेट्स आणि क्रम

प्रदात्यांमध्ये फरक आहे, त्यामुळे प्रत्येकाचे दस्तऐवज तपासा. सप्टेंबर 2026 पर्यंत:

Stripe चे दस्तऐवज असेही सांगते की घटना घडल्याच्या क्रमाने येण्याची हमी नसते, आणि तीच घटना क्वचित दोनदा येऊ शकते, म्हणून ते इव्हेंट ID ट्रॅक करण्याची शिफारस करते.

सामान्य धडा कोणत्याही प्रदात्याला लागू होतो: घटना उशिरा, एकापेक्षा जास्त वेळा आणि क्रमाबाहेर येऊ शकतात. तुमचा हँडलर आयडेम्पोटंट असावा — तीच घटना दोनदा प्रक्रिया केली तरी परिणाम एकदा प्रक्रिया केल्यासारखाच असावा.

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

तुम्ही ऑनलाइन कोर्स विकता. एक विद्यार्थी Buy क्लिक करतो, Stripe च्या होस्टेड चेकआउट पानावर पैसे देतो, आणि तुमच्या साइटवर परत पाठवला जातो.

नाजूक मार्ग: "धन्यवाद" पान कोर्स अनलॉक करते. रीडायरेक्ट दरम्यान विद्यार्थ्याने ब्राउझर बंद केला, तर त्याने पैसे दिले पण प्रवेश नाही. धन्यवाद URL कोणी अंदाजे शोधला, तर पैसे न देता प्रवेश मिळतो.

वेबहुक मार्ग:

1. Stripe ने पेमेंटची पुष्टी केल्यावर, ते /webhooks/stripe ला checkout.session.completed घटना पाठवते.
2. तुमचा बॅकएंड साइनिंग सिक्रेटने सिग्नेचरची पडताळणी करतो. ती अयशस्वी झाली तर 400 देतो आणि काहीच करत नाही.
3. ती इव्हेंट ID आधीच प्रक्रिया झाली आहे का ते तपासतो. होय असेल तर 200 देऊन थांबतो.
4. इव्हेंट ID जतन करतो, 200 देतो, आणि मग विद्यार्थ्याला प्रवेश देतो आणि स्वागत ईमेल पाठवतो.
5. धन्यवाद पान फक्त म्हणते "पेमेंट मिळाले — तुमचा कोर्स काही क्षणांत दिसेल" आणि विद्यार्थ्याची प्रवेश स्थिती तपासते.

नंतर, सदस्यता रद्द झाली किंवा कार्ड अयशस्वी झाले, तर इतर वेबहुक घटना तुमच्या ॲपला प्रवेश काढण्यास किंवा थांबवण्यास सांगतात. अशा रीतीने सबस्क्रिप्शन उत्पादने बिलिंगसोबत समक्रमित राहतात — SaaS म्हणजे काय आणि तुमच्या ॲपमध्ये पेमेंट कसे जोडायचे पहा.

महत्त्वाच्या संज्ञा

• एंडपॉइंट: तुमच्या ॲपमधील URL जो वेबहुक स्वीकारतो.
• इव्हेंट / पेलोड: काय घडले, आणि त्याचे वर्णन करणारा डेटा (सहसा JSON).
• साइनिंग सिक्रेट: सिग्नेचर पडताळण्यासाठी वापरली जाणारी सामायिक गुप्त की.
• आयडेम्पोटंट: त्याच परिणामासह एकापेक्षा जास्त वेळा चालवणे सुरक्षित.
• पोलिंग: वेबहुकची वाट पाहण्याऐवजी बदलांसाठी वारंवार API ला विचारणे.
• Tunnel: विकासादरम्यान वेबहुक पोहोचण्यासाठी लॅपटॉपला तात्पुरता सार्वजनिक URL देणारे साधन.

सामान्य चुका आणि गैरसमज

• सिग्नेचरची पडताळणी न करणे. एंडपॉइंट URL गुप्त नसतो. पडताळणीमुळेच विनंती विश्वासार्ह ठरते.
• उत्तर देण्यापूर्वी संथ काम करणे. उत्तर देण्यापूर्वी ईमेल पाठवणे किंवा PDF बनवणे यामुळे टाइमआउट होतात, ज्यामुळे पुन्हा प्रयत्न होतात, ज्यामुळे डुप्लिकेट्स येतात.
• एकदाच, क्रमाने गृहीत धरणे. इव्हेंट ID नोंदवा आणि येण्याच्या क्रमावर अवलंबून राहू नका.
• प्रिव्ह्यू URL वापरणे. वेबहुकला स्थिर, सार्वजनिक पत्ता हवा. खाजगी प्रिव्ह्यू आणि localhost इंटरनेटवरून पोहोचत नाहीत; तुमचा प्रकाशित URL वापरा (किंवा चाचणी करताना tunnel).
• टेस्ट आणि लाइव्ह सिक्रेट्स मिसळणे. प्रदाते अनेकदा टेस्ट आणि लाइव्ह मोडसाठी वेगवेगळे साइनिंग सिक्रेट्स देतात. दोन्ही साठवा आणि योग्य वापरा.
• महत्त्वाच्या निर्णयांसाठी पेलोडवर आंधळा विश्वास ठेवणे. उच्च-जोखमीच्या कृतींसाठी, घटना मिळाल्यावर प्रदात्याच्या API वरून ताजी स्थिती मिळवणे योग्य आहे.

तुमच्या AI बिल्डरला काय मागावे

सर्व्हरवर POST /webhooks/stripe एंडपॉइंट जोडा. कच्च्या विनंती बॉडी आणि STRIPE_WEBHOOK_SECRET या सिक्रेटचा वापर करून Stripe सिग्नेचर पडताळा. अवैध सिग्नेचर 400 ने नाकारा. प्रत्येक इव्हेंट ID जतन करा आणि आधीच प्रक्रिया झालेले इव्हेंट वगळा. पटकन 200 द्या, मग checkout.session.completed हाताळा: ऑर्डर पेड चिन्हांकित करा आणि पावती पाठवा. इव्हेंट प्रकार लॉग करा. चेकआउट यश पानावरून प्रवेश देऊ नका.

मग चाचणी करा: प्रदात्याच्या डॅशबोर्डवरून चाचणी इव्हेंट पाठवा, तोच पुन्हा पाठवा, आणि चुकीच्या सिग्नेचरसह विनंती पाठवा. फक्त पहिल्याने काहीतरी बदलायला हवे.

Mythex वरील वेबहुक

Mythex चा स्वतंत्र वेबहुक सेवा नाही; तुम्ही एजंटला तुमच्या ॲपच्या स्वतःच्या बॅकएंडमध्ये वेबहुक एंडपॉइंट जोडायला सांगता, आणि प्रदात्याला तुमचा प्रकाशित URL दाखवता, कारण वेबहुकला सार्वजनिक पत्ता लागतो. साइनिंग सिक्रेट तुमच्या प्रोजेक्ट सिक्रेट्समध्ये जाते, आणि लाइव्ह ॲपवर ते बदलले तर पुन्हा प्रकाशित करा. वेबहुक हाताळणे या docs रेसिपीमध्ये स्टार्टर प्रॉम्प्ट आहे, आणि पेमेंट स्वीकारणाऱ्या ॲप्ससाठी स्टोअर टेम्प्लेट्स चांगली सुरुवात आहेत.

प्रश्न