خطاف الويب (webhook) account_update وجميع أسباب انقطاع الاتصال
يستخدم Meta account_update للإبلاغ عن تغيّر حالة الاتصال. يوضح الحقل event ما حدث، وعند الإزالة يوضح disconnection_info.reason سببها. وهذا السبب يحدد ما إذا كان الرقم سيعود أو انتهى نهائيًا.
الحدث الذي ترسله Meta عند إلغاء تثبيت التطبيق من حساب.
أسباب الانقطاع المحددة التي قد ترافق الإزالة.
فترة خمول الجهاز الأساسي، وتصل كـ PRIMARY_INACTIVITY.
ما الأحداث التي يحملها account_update؟
يصل PARTNER_REMOVED عند إلغاء تثبيت التطبيق من حساب WhatsApp Business. وهذه إشارة الانقطاع المعتمدة، وهي التي يستحق بناء المنطق عليها بدل استنتاج الانقطاع من تحوّل حقل إلى false.
يصل ACCOUNT_OFFBOARDED عند إخراج الرقم بالكامل. ويصل ACCOUNT_RECONNECTED عند عودة اتصال أزيل سابقًا. وهناك أحداث الإنفاذ: ACCOUNT_RESTRICTION وACCOUNT_VIOLATION، إلى جانب الأحداث التي تتضمن أسماؤها DISABLED أو BAN.
تصل هنا أيضًا نتائج التحقق والموافقة، بأسماء أحداث تتضمن VERIFIED أو APPROVED. ينبغي للمعالج التبديل حسب اسم الحدث، ومعاملة أي اسم غير معروف كمعلومة لا كخطأ، لأن Meta تضيف أحداثًا دون إشعار.
ما أسباب الانقطاع؟
ستة أسباب، ولكل منها معنى مختلف تمامًا.
PRIMARY_INACTIVITY هي قاعدة نحو أربعة عشر يومًا: لم يُفتح تطبيق WhatsApp Business على الجهاز الأساسي. وهذا سبب قابل للاستعادة، وهو الأكثر شيوعًا بفارق كبير.
COMPANION_INACTIVITY تعني الفكرة نفسها على جهاز مرافق، لكن ضمن فترة أطول تبلغ نحو ثلاثين يومًا.
BUSINESS_DOWNGRADE يعني عودة الرقم إلى تطبيق WhatsApp للمستهلك، ما ينهي Coexistence لأن Coexistence يتطلب تطبيق Business.
CHANGE_NUMBER يعني تغيّر رقم الهاتف نفسه. ويعني USER_RE_REGISTERED إعادة تسجيله على جهاز جديد. أما ACCOUNT_DISCONNECTED فيعني أن العميل قطع الاتصال عمدًا أو أن الإنفاذ فعل ذلك.
يصل السبب أيضًا مع disconnection_info.initiated_by، الذي يوضح ما إذا كان الشخص أو النظام هو من نفّذ الإزالة.
لماذا يهم السبب أكثر من الحدث؟
لأن PARTNER_REMOVED وحده لا يخبرك بالإجراء المطلوب.
الرقم الذي أزيل بسبب PRIMARY_INACTIVITY سيعود: يفتح النشاط التجاري التطبيق، ويعيد الاتصال، ويُستأنف كل شيء. ومعاملة ذلك كعميل غادر تؤدي إلى إرسال رسالة إلغاء إلى شخص لا يزال عميلًا.
أما الرقم الذي أزيل بسبب BUSINESS_DOWNGRADE أو ACCOUNT_DISCONNECTED فهو حالة مختلفة، ومعاملته كحالة مؤقتة تعني بقاء اتصال عالق إلى الأبد.
عند وصول الإزالة بلا سبب، يكون initiated_by هو البديل: فالإزالة التي نفذها شخص تُفهم على أنها متعمدة، بينما لا تكون إزالة النظام غير المفسرة كذلك. ومن الأفضل تطبيق هذا الفرق في الكود بدل مناقشته لاحقًا مع الدعم.
الأخطاء الشائعة
- معاملة كل PARTNER_REMOVED بالطريقة نفسها. فالسبب يميز بين أسبوعين من الصمت وعميل غادر.
- استنتاج الانقطاع من تحوّل حقل إلى false بدلًا من هذا الحدث. وهذا ما ينتج إنذارات زائفة.
- التوقف عند اسم حدث غير معروف. تضيف Meta أحداثًا جديدة، وعلى المعالج تجاهل ما لا يعرفه.
يتعامل EasyCoexistence مع كل حالة بالاسم، ويسجل السبب في الجدول الزمني للاتصال، ويفصل بين إزالة الخمول القابلة للاستعادة والرقم الذي انتهى فعليًا.
الأسئلة الشائعة
هل PARTNER_REMOVED دائم؟
غالبًا لا. تصل معظم الحالات مع PRIMARY_INACTIVITY، ما يعني أن التطبيق لم يُفتح، وأن إعادة الاتصال تستعيد كل شيء.
هل تعيد إعادة الاتصال وجهة webhook؟
لا، وهذه هي المشكلة الخفية. فالوجهة عبارة عن تجاوز في اشتراك التطبيق، وتُزال معه. ويجب تطبيقها من جديد.
ما المقصود بـ COMPANION_INACTIVITY؟
الفكرة نفسها، لكن بسبب خمول جهاز مرافق بدلًا من الجهاز الأساسي، وضمن فترة أطول تبلغ نحو ثلاثين يومًا.
هل يمكن أن يصلني هذا الحدث بلا سبب؟
نعم. عندها يكون disconnection_info.initiated_by الإشارة الوحيدة إلى ما إذا كانت الإزالة متعمدة.
تابع القراءة
هل أنت مستعد للبدء؟
أعد إعداد WhatsApp Coexistence خلال دقائق، وليس أشهر. يواصل التطبيق العمل على الهاتف.
ابدأ الفترة التجريبية المجانيةتم التحقق في