म्यासेज वेबहुक

पेलोडमा के हुन्छ

एउटै डेलिभरीमा एक वा धेरै म्यासेज आउन सक्छन्, र प्रत्येकमा पठाउने व्यक्ति, id र प्रकार हुन्छ। प्रकारले अरू कुन keys उपस्थित छन् भन्ने निर्धारण गर्छ।

• पठाउने व्यक्तिको फोन नम्बर र उनीहरूले लेखेको नम्बरको phone_number_id
• डुप्लिकेसन छुट्याउने आधार बन्ने wamid म्यासेज id
• unix timestamp
• text, image, audio, video, document, sticker, location, contacts, reaction, button वा interactive प्रकार
• मिडिया प्रकारका लागि वास्तविक bytes होइन, ल्याउन प्रयोग हुने media id

रुट गरिएको नम्बरमा यो हामीकहाँ किन आउँदैन

override ले smb_message_echoes सहित यो फिल्ड तपाईंले तोकेको जुनसुकै गन्तव्यमा पठाउँछ।

Meta ले एपलाई WhatsApp Business Account का वेबहुकहरू कहाँ डेलिभर गर्ने भनेर override गर्न दिन्छ। हामी त्यो override तपाईंको यूआरएलमा सेट गर्छौं, जसले म्यासेजको बाटो हाम्रो पूर्वाधारबाट पूर्ण रूपमा हटाउँछ। हाम्रो तर्फ कुनै कपी, queue वा retention हुँदैन, किनकि डेलिभरी त्यहाँ आइपुग्दैन।

गन्तव्य सेट नभए यी इभेन्टहरू हाम्रो default callback मा फर्किन्छन्, जहाँ handler ले तिनलाई persist नगरी हटाउँछ। स्टोरेजबारेको दाबी र code path बीच यही फरक हो: कुराकानीको सामग्री जाने ठाउँ नै हुँदैन।

सही तरिकाले स्वीकृति दिनु

काम गर्नुअघि 200 फर्काउनुहोस्, पछि होइन।

ढिलो प्रतिक्रियालाई Meta ले त्रुटि मानेर रिट्राइ गर्छ, त्यसैले inline प्रक्रिया गर्ने handler ले एउटै म्यासेज एकभन्दा बढी पटक देख्न सक्छ। तुरुन्त प्रतिक्रिया दिनुहोस्, पेलोडलाई queue वा background task मा राख्नुहोस् र अनुरोधबाहिर काम हुन दिनुहोस्।

serverless मा यो वैकल्पिक होइन। प्रतिक्रिया दिएपछि पनि काम गरिरहने function जवाफ फर्काउनेबित्तिकै freeze हुन सक्छ, त्यसैले स्वीकृति र प्रक्रिया वास्तवमै अलग हुनुपर्छ।

डुप्लिकेसन छुट्याउने

सधैं wamid का आधारमा गर्नुहोस्, किनकि रिट्राइ असामान्य होइन, सामान्य प्रक्रिया हो।

तपाईंको तर्फको बगसँग सम्बन्ध नभएका कारणले एउटै म्यासेज दुई पटक आउन सक्छ: ढिलो प्रतिक्रिया, network timeout वा डेलिभरीबीच भएको deploy। देखिएका id हरू स्टोर गरेर दोहोरिएका म्यासेज छोड्नु केही लाइनको काम हो, र यसले ग्राहकलाई एक पटक जवाफ दिने कि दुई पटक भन्ने फरक पार्छ।

Coexistence नम्बरमा यो अझ महत्त्वपूर्ण हुन्छ, किनकि smb_message_echoes उही बाटोमा आउँछ। हरेक इभेन्टलाई नयाँ ठान्ने handler ले मानवले पहिले नै जवाफ दिइसकेको ठाउँमा फेरि प्रतिक्रिया पठाउन सक्छ।

सामान्य गल्तीहरू

• 200 फर्काउनुअघि प्रक्रिया गर्नु। Meta ले ढिलो प्रतिक्रियामा रिट्राइ गर्छ र तपाईंले म्यासेज दुई पटक सम्हाल्नुहुन्छ।
• डुप्लिकेसन छुट्याउने प्रक्रिया छोड्नु। रिट्राइ डिजाइनकै भाग हुन्, अपवाद होइनन्।
• पेलोडमा मिडियाका bytes अपेक्षा गर्नु। यसले ल्याउनका लागि media id बोक्छ।

बारम्बार सोधिने प्रश्नहरू

पढ्दै जानुहोस्