میسجز کا ویب ہک
`messages` وہ فیلڈ ہے جو آپ کے نمبر پر کسٹمر کے بھیجے ہوئے ٹیکسٹ، میڈیا، جوابات، ری ایکشنز اور انٹرایکٹو جوابات لاتا ہے۔ routed Coexistence نمبر پر یہ Meta سے سیدھا آپ کے اینڈ پوائنٹ تک جاتا ہے اور کبھی provider سے نہیں گزرتا۔
کسٹمر کے آنے والے میسجز لانے والا ویب ہک فیلڈ۔
میسج id کا وہ prefix جس سے دوبارہ آنے والی درخواستیں الگ کی جاتی ہیں۔
وہ اسٹیٹس جس کی Meta کسی بھی پروسیسنگ سے پہلے فوری توقع کرتی ہے۔
پے لوڈ میں کیا ہوتا ہے
ایک delivery میں ایک یا زیادہ میسجز آ سکتے ہیں، اور ہر میسج میں بھیجنے والے، id اور type کی معلومات ہوتی ہیں۔ type طے کرتا ہے کہ کون سی دوسری keys موجود ہوں گی۔
- بھیجنے والے کا فون نمبر اور اس نمبر کا phone number id جس پر اس نے لکھا۔
- wamid میسج id، جس پر deduplication کی بنیاد ہے۔
- unix timestamp۔
- ایک type: text، image، audio، video، document، sticker، location، contacts، reaction، button یا interactive۔
- میڈیا types کے لیے media id، جس سے میڈیا حاصل کیا جاتا ہے، خود bytes نہیں۔
routed نمبر پر یہ ہم تک کیوں نہیں پہنچتا
کیونکہ override اس فیلڈ کو `smb_message_echoes` کے ساتھ آپ کے منتخب کردہ destination پر بھیج دیتا ہے۔
Meta کسی ایپ کو یہ override کرنے دیتی ہے کہ WhatsApp Business Account اپنے ویب ہکس کہاں بھیجے۔ ہم یہ override آپ کے URL پر سیٹ کرتے ہیں، اس لیے میسج کا راستہ مکمل طور پر ہمارے infrastructure سے باہر رہتا ہے۔ ہماری طرف نہ اس کی copy بنتی ہے، نہ queue اور نہ retention، کیونکہ delivery وہاں پہنچتی ہی نہیں۔
جب کوئی destination سیٹ نہ ہو تو یہ events ہمارے default callback پر آتے ہیں، جہاں handler انہیں محفوظ کیے بغیر drop کر دیتا ہے۔ storage کے دعوے اور code path میں یہی فرق ہے: conversation content کے جانے کے لیے کوئی جگہ نہیں۔
درست طریقے سے تصدیق کرنا
کام شروع کرنے سے پہلے 200 واپس کریں، بعد میں نہیں۔
Meta سست جواب کو failure سمجھتی ہے اور دوبارہ کوشش کرتی ہے، اس لیے inline پروسیسنگ کرنے والا handler ایک ہی میسج ایک سے زیادہ بار دیکھ سکتا ہے۔ فوراً جواب دیں، پے لوڈ کو queue یا background task میں ڈالیں، اور کام request سے باہر ہونے دیں۔
serverless میں یہ optional نہیں۔ جواب دینے کے بعد کام جاری رکھنے والا function اسی لمحے freeze ہو سکتا ہے، اس لیے acknowledgement اور processing واقعی الگ ہونے چاہییں۔
دوبارہ آنے والے میسجز الگ کرنا
ہمیشہ wamid کی بنیاد پر کریں، کیونکہ retries معمول کی بات ہیں، کوئی غیر معمولی واقعہ نہیں۔
ایک ہی میسج آپ کی طرف کسی bug کے بغیر بھی دو بار آ سکتا ہے: سست جواب، network timeout یا delivery کے دوران deploy۔ دیکھے گئے ids محفوظ کرنا اور repeats کو skip کرنا چند لائنوں کا کام ہے، اور یہی فرق ہے کہ کسٹمر کو ایک بار جواب ملے یا دو بار۔
Coexistence نمبر پر یہ زیادہ اہم ہے، کیونکہ `smb_message_echoes` اسی راستے سے آتا ہے۔ ہر event کو نیا سمجھنے والا handler اس انسان کے جواب پر دوبارہ جواب دے گا جس نے پہلے ہی کسٹمر کو جواب دیا ہے۔
عام غلطیاں
- 200 واپس کرنے سے پہلے پروسیسنگ کرنا۔ Meta سست جواب پر دوبارہ کوشش کرتی ہے اور آپ میسج دو بار handle کرتے ہیں۔
- deduplication چھوڑ دینا۔ Retries ڈیزائن کا حصہ ہیں، کوئی نایاب صورت نہیں۔
- پے لوڈ میں media bytes کی توقع کرنا۔ اس میں حاصل کرنے کے لیے media id ہوتا ہے۔
EasyCoexistence اس فیلڈ کو Meta سے سیدھا آپ کے اینڈ پوائنٹ تک route کرتا ہے اور صرف monitoring کے لیے ضروری operational events رکھتا ہے، اس لیے conversation content کے لیے ہماری storage تک کوئی راستہ نہیں۔
اکثر پوچھے جانے والے سوالات
کیا EasyCoexistence میرے کسٹمرز کے میسجز دیکھتا ہے؟
نہیں۔ override اس فیلڈ کو آپ کے اینڈ پوائنٹ پر بھیجتا ہے۔ ہمارے fallback callback تک پہنچنے والی ہر چیز محفوظ کیے بغیر drop کر دی جاتی ہے۔
کیا ایک request میں کئی میسجز آ سکتے ہیں؟
ہاں۔ ایک delivery میں ایک سے زیادہ میسجز ہو سکتے ہیں، اس لیے handlers کو پہلے میسج پر رکنے کے بجائے سب پر iterate کرنا چاہیے۔
میں میڈیا کیسے حاصل کروں؟
پے لوڈ میں media id ہوتا ہے۔ نمبر کے access token سے اس id کے ذریعے URL حاصل کریں، پھر میڈیا download کریں۔
smb_message_echoes کیا ہے؟
یہ companion field ہے جو WhatsApp Business ایپ سے آپ کی ٹیم کے بھیجے ہوئے میسجز لاتا ہے۔ یہ صرف Coexistence نمبرز پر موجود ہوتا ہے۔
مزید پڑھیں
شروع کرنے کے لیے تیار ہیں؟
WhatsApp Coexistence چند منٹ میں سیٹ اپ کریں، مہینوں میں نہیں۔ ایپ فون پر کام کرتی رہتی ہے۔
فری ٹرائل شروع کریںتصدیق شدہ تاریخ