WhatsApp वेबहुक: मैसेज सीधे आपके सर्वर पर भेजना

Meta वेबहुक पर वास्तव में क्या भेजता है?

इवेंट अलग-अलग श्रेणियों में आते हैं और इनके बीच का अंतर आपका आर्किटेक्चर तय करता है।

मैसेज-पथ में ग्राहक के भेजे मैसेज आते हैं। Coexistence नंबर पर WhatsApp Business ऐप से आपकी टीम द्वारा भेजे गए मैसेज की प्रतिध्वनियां भी आती हैं। इनके फ़ील्ड messages और smb_message_echoes हैं और इन्हीं में बातचीत की सामग्री होती है।

ऑपरेशनल पथ में बाकी सब आता है: कनेक्शन स्टेटस बदलने पर account_update, क्वालिटी या थ्रूपुट बदलने पर phone_number_quality_update, account_alerts, account_review_update, business_capability_update और phone_number_name_update। इनमें बातचीत की सामग्री नहीं होती और इन्हीं से मॉनिटरिंग तैयार होती है।

जो प्रदाता खुद को मैसेज-पथ में रखता है, उसे पहला समूह मिलता है। जो ऐसा नहीं करता, उसे नहीं मिलता।

Meta किसी एंडपॉइंट की पुष्टि कैसे करता है?

किसी भी डिलीवरी से पहले GET अनुरोध भेजकर। यही वह चरण है जिसमें गड़बड़ी होने पर पूरा सेटअप तैयार दिखता है, लेकिन कोई मैसेज नहीं मिलता।

Meta आपके यूआरएल को hub.mode को subscribe, आपके hub.verify_token और hub.challenge मान के साथ कॉल करता है। आपके एंडपॉइंट को उस challenge को raw response body के रूप में लौटाना होता है, JSON में लपेटकर नहीं और उसमें कुछ जोड़कर नहीं। ऐसा न होने पर Meta डिलीवरी शुरू नहीं करता और किसी डैशबोर्ड में इसका संकेत नहीं मिलता।

एंडपॉइंट HTTPS भी होना चाहिए। ऐसा एंडपॉइंट जो चुपचाप 404 लौटाता है या ऐसी authentication layer के पीछे है जो Meta को अस्वीकार करती है, पहली बार मैसेज न आने तक सही सेटअप जैसा ही दिखता है।

क्या डेस्टिनेशन आपके अपने सर्वर पर भेजा जा सकता है?

हाँ, और यहीं प्रदाताओं के बीच अंतर आता है।

Meta किसी WhatsApp Business Account के वेबहुक किस जगह पहुँचेंगे, इसे ऐप से override करने देता है। हम यह override आपके यूआरएल पर सेट करते हैं, जिससे मैसेज-पथ के इवेंट हमारे callback के बजाय आपके पास जाते हैं। ऑपरेशनल इवेंट हमारे पास रहते हैं, क्योंकि डैशबोर्ड और अलर्टिंग उन्हीं से बनते हैं।

इसका असर आर्किटेक्चर पर पड़ता है, किसी प्रकाशित नीति पर नहीं। बातचीत की सामग्री हमारी ओर संग्रहीत नहीं हो सकती, क्योंकि वह हमारे पास आती ही नहीं। जिस खाते पर कोई override सेट नहीं है, वह हमारे डिफ़ॉल्ट callback पर लौटता है और handler इन इवेंट को बिना सहेजे हटा देता है।

किसी नंबर के दोबारा कनेक्ट होने पर डेस्टिनेशन का क्या होता है?

वह हट जाता है। लगभग कोई भी इस विफलता की योजना नहीं बनाता।

डेस्टिनेशन फ़ोन नंबर की संपत्ति नहीं है। यह WhatsApp Business Account के लिए हमारे ऐप के subscription पर लगा override है। Meta के चौदह दिन की निष्क्रियता वाले नियम या किसी अन्य कारण से कनेक्शन हटने पर ऐप उस खाते से uninstall हो जाता है और override भी उसके साथ चला जाता है।

दोबारा कनेक्ट करने से भेजना और मॉनिटरिंग वापस आ जाती है। इससे आपके सर्वर पर डिलीवरी वापस नहीं आती और कोई गड़बड़ी रिपोर्ट नहीं होती। इसलिए पहला संकेत अक्सर ग्राहक का यह कहना होता है कि किसी ने जवाब नहीं दिया। हम हर reconnection पर override फिर से लागू करते हैं, क्योंकि ऐसा एक वास्तविक नंबर के साथ हुआ था जो ठीक से दोबारा कनेक्ट हुआ, फिर भी उसके मैसेज आना बंद हो गए।

आम गड़बड़ियाँ

• पुष्टि वाले GET से JSON लौटाना। Meta को raw hub.challenge मान और उसके अलावा कुछ नहीं चाहिए।
• अस्थायी या test यूआरएल इस्तेमाल करना। उसे बनाने वाला टूल सुनना बंद करने के बाद भी Meta उसी पर डिलीवरी करता रहता है।
• यह मान लेना कि reconnection के बाद डेस्टिनेशन बना रहता है। वह ऐप subscription पर रहता है और ऐप के साथ uninstall हो जाता है।
• एंडपॉइंट को ऐसी authentication के पीछे रखना जो Meta के अनुरोध को अस्वीकार करती है।

अक्सर पूछे जाने वाले सवाल

पढ़ना जारी रखें