WhatsApp वेबहुक एंडपॉइंट की पुष्टि
कोई भी इवेंट भेजने से पहले Meta आपके एंडपॉइंट को hub.mode, hub.verify_token और hub.challenge के साथ GET अनुरोध भेजता है। आपके एंडपॉइंट को टोकन की तुलना करनी होगी और चैलेंज को कच्ची बॉडी के रूप में लौटाना होगा। इसके अलावा कुछ भी होने पर डिलीवरी शुरू नहीं होती।
वह मान जिसे जवाब की बॉडी में वापस भेजना होता है।
पुष्टि अनुरोध में hub.mode का मान।
Meta केवल इसी स्कीम की पुष्टि करेगा। कॉल से पहले HTTP अस्वीकार हो जाता है।
Meta वास्तव में क्या भेजता है?
Meta आपके यूआरएल पर तीन क्वेरी पैरामीटर के साथ GET अनुरोध भेजता है। hub.mode को subscribe पर सेट किया जाता है। hub.verify_token वह टोकन है जिसे डेस्टिनेशन सेट करते समय आपने कॉन्फ़िगर किया था। hub.challenge वह मान है जिसे Meta इस प्रयास के लिए बनाता है।
आपके एंडपॉइंट को hub.verify_token की तुलना आपके चुने हुए टोकन से करनी चाहिए। टोकन मेल खाने पर 200 जवाब के साथ hub.challenge को पूरी जवाब-बॉडी के रूप में लौटाएं। इसे JSON में न लपेटें, इसके चारों ओर कोट न लगाएं और आखिर में वह नई लाइन न जोड़ें जिसे कुछ फ़्रेमवर्क डिफ़ॉल्ट रूप से जोड़ते हैं।
टोकन मेल न खाए तो 403 जवाब दें। यही पूरा प्रोटोकॉल है और इसे जानबूझकर छोटा रखा गया है।
गलत जवाब चुपचाप क्यों विफल होता है?
क्योंकि पुष्टि का विफल होना आपके सिस्टम में गड़बड़ी नहीं, Meta के सिस्टम में अनुपस्थिति है।
जब चैलेंज सही तरीके से वापस नहीं भेजा जाता, Meta उस डेस्टिनेशन पर डिलीवरी शुरू ही नहीं करता। आपका सर्वर पुष्टि के लिए 200 लौटाता है, आपके लॉग में अनुरोध आने का रिकॉर्ड दिखता है और किसी भी डैशबोर्ड पर समस्या नहीं दिखती। एकमात्र संकेत यह है कि मैसेज कभी नहीं आते। ज़्यादातर लोग इसे हैंडशेक की समस्या के बजाय Coexistence की समस्या समझते हैं।
इसीलिए कॉल करने से पहले पुष्टि करना उपयोगी है। Graph अनुरोध भेजने से पहले हम जांचते हैं कि यूआरएल HTTPS है और पुष्टि टोकन दिया गया है। इससे गलत डेस्टिनेशन तुरंत विफल हो जाता है और कनेक्टेड जैसा नहीं दिखता।
पुष्टि को और क्या रोक सकता है?
ऐसी तीन चीज़ें जिनका कोड से कोई संबंध नहीं है।
एंडपॉइंट के सामने प्रमाणीकरण। कोई गेटवे, basic auth लेयर या IP allowlist Meta के अनुरोध को अस्वीकार कर सकती है, और Meta के पास देने के लिए कोई क्रेडेंशियल नहीं है। पुष्टि रूट इनके बिना पहुंच योग्य होना चाहिए।
रीडायरेक्ट। Meta आपके दिए हुए यूआरएल पर कॉल करता है, और canonical host पर 301 रीडायरेक्ट ऐसे फ़ॉलो नहीं होता कि हैंडशेक पूरा हो सके। उसे अंतिम यूआरएल दें।
और ऐसा फ़्रेमवर्क जो जवाब को सीरियलाइज़ करता है। ऐसे हैंडलर से स्ट्रिंग लौटाने पर, जो हर चीज़ को JSON में लपेटता है, बॉडी में चैलेंज के चारों ओर कोट आ जाते हैं और वह मेल नहीं खाता।
आम गड़बड़ियाँ
- JSON लौटाना। बॉडी में बिना किसी अतिरिक्त चीज़ के कच्चा चैलेंज मान होना चाहिए।
- एंडपॉइंट को प्रमाणीकरण के पीछे रखना। Meta के पास क्रेडेंशियल नहीं हैं और अनुरोध अस्वीकार हो जाएगा।
- Meta को ऐसा यूआरएल देना जो रीडायरेक्ट करता है। अंतिम यूआरएल का इस्तेमाल करें।
EasyCoexistence Meta को कॉल करने से पहले जांचता है कि डेस्टिनेशन HTTPS है और उसमें पुष्टि टोकन है। असफल हैंडशेक को कनेक्शन टाइमलाइन में दर्ज किया जाता है।
अक्सर पूछे जाने वाले सवाल
मुझे कौन-सा टोकन इस्तेमाल करना चाहिए?
आप अपनी पसंद की कोई भी स्ट्रिंग चुन सकते हैं। इससे आपका एंडपॉइंट Meta के अनुरोध को उस व्यक्ति के अनुरोध से अलग पहचान सकता है जिसे यूआरएल पता चल गया हो।
पुष्टि कितनी बार होती है?
सेटअप के समय और हर बार डेस्टिनेशन सेट किए जाने पर। काम कर रहे एंडपॉइंट की हर इवेंट पर दोबारा पुष्टि नहीं होती।
क्या मैं खुद इसका परीक्षण कर सकता हूं?
हां। अपने एंडपॉइंट को तीनों पैरामीटर के साथ कॉल करें और जांचें कि बॉडी में ठीक वही चैलेंज मान वापस आता है।
अगर पुष्टि के दौरान मेरा सर्वर बंद था तो क्या होगा?
हैंडशेक विफल होगा और डेस्टिनेशन सक्रिय नहीं होगा। इसे फिर से सेव करने पर पुष्टि दोबारा चलेगी।
पढ़ना जारी रखें
शुरू करने के लिए तैयार हैं?
WhatsApp Coexistence को महीनों में नहीं, मिनटों में कॉन्फ़िगर करें। ऐप्लिकेशन मोबाइल पर काम करता रहता है।
मुफ़्त ट्रायल शुरू करेंइस तारीख को सत्यापित