WhatsApp सर्विस मैसेज

सर्विस मैसेज वह कुछ भी है जो आप भेजते हैं और जो पहले से स्वीकृत टेम्प्लेट नहीं है: वह फ़्री-फ़ॉर्म कंटेंट जो बिज़नेस किसी खुली बातचीत के अंदर भेजता है। POST /v1/whatsapp/messages ठीक नौ सर्विस-मैसेज कंटेंट आर्म्स में से एक, या एक टेम्प्लेट ले जाता है। यह पेज इन नौ आर्म्स की साझा बातें बताता है; हर आर्म का अपना पेज उसकी वायर शेप और सीमाएँ बताता है।

एक रिक्वेस्ट template में से ठीक एक या इन नौ फ़ील्ड्स में से एक ले जाती है। ऐसी रिक्वेस्ट जिसमें इनमें से कोई नहीं है, या एक से ज़्यादा हैं, 422 के साथ अस्वीकार कर दी जाती है।

सर्विस मैसेज, यानी ऊपर दिए गए नौ आर्म्स में से कोई भी, केवल खुली 24 घंटे की कस्टमर सर्विस विंडो के अंदर ही डिलीवर होता है। कॉन्टैक्ट आपके बिज़नेस नंबर पर मैसेज या कॉल करके यह विंडो खोलता है, और उसका हर अगला मैसेज इसे 24 घंटे पर रीसेट कर देता है।

बंद विंडो में भेजा गया सर्विस मैसेज तुरंत अस्वीकार कर दिया जाता है: रिक्वेस्ट 422 E15044 WhatsAppServiceWindowClosed लौटाती है, और कुछ भी बनाया या चार्ज नहीं किया जाता। इसके बजाय एक स्वीकृत टेम्प्लेट भेजें; यह विंडो की परवाह किए बिना कॉन्टैक्ट तक पहुँचता है, और उनका जवाब विंडो फिर से खोल देता है। ऐसी विंडो जो accept और dispatch के बीच के क्षण में बंद हो जाती है, तब भी विफल होती है, लेकिन एसिंक्रोनस रूप से: मैसेज last_error पर service_window_expired के साथ failed पर पहुँचता है।

Accept-time जाँच बेस्ट एफ़र्ट है, गारंटी नहीं: गेट ओपन फ़ेल होता है, इसलिए स्टोर मिस या रीड एरर सेंड को ब्लॉक करने के बजाय गुज़रने देता है। इसलिए 202 इस बात का प्रमाण नहीं है कि सेंड के समय विंडो खुली थी; अंतिम सिग्नल मैसेज का अपना स्टेटस है, accept रिस्पॉन्स नहीं।

हर सर्विस मैसेज को from भी चाहिए, एक ऐसा नंबर जो आपके वर्कस्पेस का है। Bird के मैनेज्ड नंबर इसे नहीं ले जा सकते, इसलिए सर्विस मैसेज के लिए पहले आपका अपना नंबर कनेक्ट होना ज़रूरी है; देखें फ़ोन नंबर सेटअप।

पूरे लाइफ़साइकल के लिए कस्टमर सर्विस विंडो देखें: विंडो कैसे खुलती है, क्या इसे रीसेट करता है, और इसे कैसे ट्रैक किया जाता है।

image, video, audio, sticker, और document सभी एक url लेते हैं जो ऐसी फ़ाइल की ओर इंगित करता है जिसे WhatsApp भेजते समय फ़ेच करता है, न कि कोई ऐसी फ़ाइल जिसे आप Bird पर अपलोड करते हैं। Bird accept पर URL की शेप जाँचता है, कुछ भी enqueue होने से पहले:

http URL को accept पर 422 के साथ अस्वीकार कर दिया जाता है, भले ही WhatsApp स्वयं इसे ठीक से फ़ेच कर ले। यह Bird की नीति है, WhatsApp द्वारा लगाई गई सीमा नहीं।

Bird फ़ाइल का आकार, उसका MIME टाइप, या URL पहुँच योग्य है या नहीं, इसकी जाँच नहीं करता। WhatsApp मैसेज डिस्पैच करते समय URL को स्वयं फ़ेच करता है, इसलिए एक signed URL को उस समय के बाद तक वैध रहना चाहिए, न कि केवल रिक्वेस्ट भेजते समय; प्राइवेट या एक्सपायर्ड URL तब विफल होता है जब WhatsApp इसे फ़ेच करने की कोशिश करता है। WhatsApp फ़ेच किए गए URL को लगभग 10 मिनट तक कैश भी करता है, इसलिए उस विंडो के अंदर वही URL दोबारा भेजने पर फिर से फ़ेच करने के बजाय पहले वाला फ़ेच सर्व होता है।

मीडिया सेंड किसी भी WhatsApp मैसेज की तरह वही async पथ अपनाता है: Bird 202 लौटाता है और मैसेज accept करता है, फिर WhatsApp डिस्पैच करते समय URL फ़ेच करता है। अगर वह फ़ेच विफल होता है, तो मैसेज last_error पर media_rejected के साथ failed पर पहुँचता है, जो अंदर Meta का 131053 है।

media_rejected एक छत्र कोड है जो ओवरसाइज़ फ़ाइल, 404, DNS विफलता, और गलत MIME टाइप सभी को कवर करता है; Bird इसे आगे विभाजित नहीं करता, इसलिए हर कारण के लिए अलग कोड की उम्मीद न करें।

एसिंक्रोनस रूप से विफल हुआ मीडिया सेंड फिर भी चार्ज होता है। चार्जिंग तब होती है जब Bird accepted सेंड को प्रोसेस करता है, WhatsApp द्वारा URL फ़ेच करने से पहले, और एक बार चार्ज लग जाने के बाद कोई रिफ़ंड पथ नहीं है। इसके अनुसार बजट बनाएँ: media_rejected में बाद में विफल होने वाले मैसेज की लागत उतनी ही है जितनी डिलीवर हुए मैसेज की।

इनबाउंड मैसेज उन्हीं नौ आर्म्स में से एक ले जाता है, इसलिए आप जो फ़ील्ड पढ़ते हैं वह कॉन्टैक्ट द्वारा उपयोग किए गए प्रकार से मेल खाती है। कॉन्टैक्ट कार्ड उसी contact_cards फ़ील्ड पर वापस पढ़े जाते हैं, चाहे कॉन्टैक्ट ने शेयर किया हो या आपने भेजा हो। WhatsApp मैसेज प्राप्त करना API पर इनबाउंड मैसेज पढ़ना, कॉन्टैक्ट द्वारा भेजा गया मीडिया फ़ेच करना, और whatsapp.received webhook को कवर करता है।