messages वेबहुक
messages हे ग्राहक तुमच्या नंबरवर पाठवतो ते सर्व वाहून नेणारे फील्ड आहे: मजकूर, मीडिया, प्रत्युत्तरे, प्रतिक्रिया आणि परस्परसंवादी प्रतिसाद. routed Coexistence नंबरवर ते Meta कडून थेट तुमच्या endpoint वर जाते, provider मार्फत कधीच नाही.
ग्राहकांचे येणारे मेसेज वाहून नेणारे वेबहुक फील्ड.
पुन्हा आलेल्या मेसेजेसची डुप्लिकेशन टाळण्यासाठी वापरल्या जाणाऱ्या message id चा prefix.
कोणतीही प्रक्रिया करण्यापूर्वी Meta ला पटकन अपेक्षित असलेला स्टेटस.
पेलोडमध्ये काय असते
एका delivery मध्ये एक किंवा अधिक मेसेजेस असू शकतात. प्रत्येक मेसेजमध्ये पाठवणारा, id आणि type असतो. type ठरवतो की इतर कोणत्या keys उपस्थित असतील.
- पाठवणाऱ्याचा फोन नंबर आणि त्याने मेसेज पाठवलेल्या नंबरचा phone number id.
- wamid message id, ज्यावर डुप्लिकेशन टाळण्याची प्रक्रिया आधारित असते.
- unix timestamp.
- एक type: text, image, audio, video, document, sticker, location, contacts, reaction, button किंवा interactive.
- मीडिया प्रकारांसाठी bytes ऐवजी fetch करण्यासाठी media id.
routed नंबरवर ते आमच्यापर्यंत का पोहोचत नाही
override हे फील्ड आणि smb_message_echoes तुम्ही निवडलेल्या कोणत्याही destination कडे पाठवते.
WhatsApp Business Account चे वेबहुक्स कुठे वितरित करायचे, हे ॲप override करू शकते. आम्ही तो override तुमच्या यूआरएलवर सेट करतो, त्यामुळे मेसेजचा मार्ग आमच्या infrastructure पासून पूर्णपणे वेगळा होतो. आमच्या बाजूला copy, queue किंवा retention नसते, कारण delivery तिथे येतच नाही.
destination सेट केलेले नसल्यास, हे events आमच्या default callback कडे fॉलबॅक होतात आणि handler ते persist न करता टाकून देतो. storage बाबतच्या दाव्यापेक्षा code path वेगळा असतो: conversation content जाण्यासाठी आमच्याकडे जागाच नाही.
योग्य प्रकारे पुष्टी देणे
काम पूर्ण झाल्यावर नव्हे, काम सुरू करण्यापूर्वी 200 परत करा.
Meta धीमा प्रतिसाद त्रुटी मानते आणि पुन्हा प्रयत्न करते. त्यामुळे inline प्रक्रिया करणाऱ्या handler ला तोच मेसेज एकापेक्षा जास्त वेळा दिसू शकतो. त्वरित प्रतिसाद द्या, पेलोड queue किंवा background task वर ठेवा आणि विनंतीबाहेर प्रक्रिया होऊ द्या.
serverless मध्ये हे ऐच्छिक नाही. function ने प्रतिसाद दिल्यानंतरही काम सुरू ठेवले, तर ती त्याच क्षणी freeze होऊ शकते. त्यामुळे पुष्टी आणि प्रक्रिया खरोखर वेगवेगळ्या असल्या पाहिजेत.
डुप्लिकेशन टाळणे
नेहमी wamid वर आधारित करा, कारण retries अपवाद नसून नेहमीची बाब आहेत.
तुमच्या बाजूच्या त्रुटीशी संबंध नसलेल्या कारणांमुळे तोच मेसेज दोनदा येऊ शकतो: धीमा प्रतिसाद, network timeout किंवा delivery दरम्यान झालेला deploy. पाहिलेले ids साठवून पुनरावृत्ती टाळणे काही ओळींचे काम आहे. त्यामुळे ग्राहकाला एकदाच उत्तर मिळते, दोनदा नाही.
Coexistence नंबरवर हे अधिक महत्त्वाचे आहे, कारण smb_message_echoes त्याच मार्गाने येते. प्रत्येक event नवीन मानणारा handler, टीममधील एखाद्याने आधीच उत्तर दिलेले असताना त्यावर पुन्हा उत्तर देऊ शकतो.
सामान्य चुका
- 200 परत करण्यापूर्वी प्रक्रिया करणे. Meta धीमा प्रतिसाद पुन्हा पाठवते आणि मेसेज दोनदा हाताळला जातो.
- डुप्लिकेशन टाळण्याची प्रक्रिया वगळणे. Retries हे डिझाइनचा भाग आहेत, क्वचित घडणारी बाब नाही.
- पेलोडमध्ये media bytes असतील अशी अपेक्षा ठेवणे. त्यात fetch करण्यासाठी media id असतो.
EasyCoexistence हे फील्ड Meta कडून थेट तुमच्या endpoint वर पाठवते आणि monitoring साठी आवश्यक operational events एवढेच ठेवते. त्यामुळे conversation content आमच्या storage पर्यंत पोहोचू शकत नाही.
वारंवार विचारले जाणारे प्रश्न
EasyCoexistence माझ्या ग्राहकांचे मेसेज पाहते का?
नाही. override हे फील्ड तुमच्या endpoint वर पाठवतो. आमच्या fallback callback पर्यंत पोहोचणारे काहीही persist न करता टाकून दिले जाते.
एका विनंतीत अनेक मेसेजेस येऊ शकतात का?
हो. एका delivery मध्ये एकापेक्षा जास्त मेसेजेस असू शकतात. त्यामुळे handler ने पहिला मेसेज वाचण्याऐवजी सर्वांवर iterate केले पाहिजे.
मीडिया कसा मिळवायचा?
पेलोडमध्ये media id असतो. नंबरच्या access token चा वापर करून त्याद्वारे यूआरएल fetch करा, नंतर download करा.
smb_message_echoes म्हणजे काय?
WhatsApp Business ॲपमधून तुमची टीम पाठवते ते वाहून नेणारे companion फील्ड. ते फक्त Coexistence नंबरवर अस्तित्वात असते.
पुढे वाचा
सुरुवात करण्यासाठी तयार आहात?
WhatsApp Coexistence काही मिनिटांत सेट करा, काही महिन्यांत नाही. ॲप फोनवर काम करत राहते.
मोफत ट्रायल सुरू करापडताळले: