Meta Tech Provider

إرسال واستقبال WhatsApp من Node.js

الاستقبال عبارة عن نقطة نهاية (endpoint) تستجيب لطلب GET للتحقق من Meta وتقبل طلبات POST. أما الإرسال فهو استدعاء fetch إلى Cloud API باستخدام معرّف رقم الهاتف ورمز الوصول (token). لا توجد SDK خاصة بنا ولا شيء لتثبيته.

2 handlers

طلب GET للتحقق من Meta وطلب POST للأحداث.

24 hours

النافذة الزمنية بعد رسالة العميل التي يمكن خلالها إرسال نص حر.

131047

الخطأ الذي يظهر عند إرسال نص حر خارج تلك النافذة.

كيف تستقبل الرسائل في Node؟

نقطة نهاية واحدة بطريقتين، باستخدام Express أو Fastify أو معالج مسارات Next أو خادم عادي.

يستجيب طلب GET للتحقق من Meta: اقرأ hub.mode و hub.verify_token و hub.challenge من الاستعلام، وقارن الرمز برمذك، ثم أعد التحدي كنص عادي. إعادته بصيغة JSON هي الغلطة المعتادة، وتنتج نقطة نهاية لا تستقبل أي شيء رغم أنها تبدو صحيحة.

يستقبل طلب POST الأحداث. أرسل استجابة 200 فورًا ثم عالجها بعد ذلك. تعيد Meta محاولة أي شيء بطيء، والمعالج الذي ينفذ عمله قبل الاستجابة سيرى الرسالة نفسها أكثر من مرة. خصوصًا في الخوادم عديمة الحالة، إن الإعادة أولًا ووضع العمل في قائمة انتظار هو ما يمنع بدء التشغيل البارد من تحويل الطلب إلى نسخة مكررة.

كيف ترسل؟

استخدم fetch إلى نقطة نهاية رسائل Cloud API الخاصة بمعرّف رقم الهاتف، مع إرسال رمز الوصول في ترويسة bearer.

لا شيء هنا خاص بنا، لذلك يطابق الطلب وثائق Meta نفسها تمامًا، ولا يوجد غلاف يجب تعلمه أو الالتزام به. توجد القيمتان في لوحة التحكم، وتعيدهما الدالة get_api_credentials عبر موصل MCP إذا كان مساعد ينفذ الإعداد.

يعتمد محتوى الطلب على التوقيت. خلال 24 ساعة من آخر رسالة واردة من العميل، أرسل كائنًا نصيًا. خارج هذه المدة، أرسل كائن قالب يتضمن اسم القالب المعتمد واللغة. ينجح الكود الذي يرسل النصوص فقط في كل الاختبارات، ثم يفشل عند وصول أول رسالة ليلًا.

ما المختلف في الخوادم عديمة الحالة؟

هناك أمران، وكلاهما يتعلق بانتهاء الدالة قبل انتهاء العمل.

إرسال 200 ثم مواصلة المعالجة لا يصمد أمام دالة تتجمد لحظة استجابتها. استخدم ما توفره منصتك لإبقاء العمل حيًا بعد الاستجابة، أو ادفع البيانات إلى قائمة انتظار ودع دالة منفصلة تتعامل معها. تحتاج Meta إلى الإقرار بسرعة فقط؛ ولا تحتاج إلى اكتمال العمل.

كما تجعل بدايات التشغيل الباردة الاستجابات البطيئة أكثر احتمالًا، ما يعني مزيدًا من المحاولات ومزيدًا من النسخ المكررة. إزالة التكرار اعتمادًا على معرّف الرسالة wamid ليست اختيارية هنا؛ بل هي ما يجعل النظام موثوقًا.

الأخطاء الشائعة

  • إعادة التحدي بصيغة JSON بدلًا من إعادة نص الجسم الخام.
  • تنفيذ العمل قبل إرسال الاستجابة 200. في الخوادم عديمة الحالة قد تتجمد الدالة لحظة استجابتها.
  • تخطي إزالة التكرار. تعيد Meta المحاولة عمدًا، والنسخ المكررة أمر طبيعي وليست حالة نادرة.
إنجاز ذلك باستخدام EasyCoexistence

صِل الرقم عبر easycoexistence.com، واضبط وجهة خطاف الويب (webhook) على مسارك، ثم اقرأ معرّف رقم الهاتف ورمز الوصول من لوحة التحكم. يبدأ السعر من US$ 9 لكل رقم شهريًا، وينخفض إلى US$ 2 عند زيادة الحجم، مع أول 7 أيام مجانًا.

الأسئلة الشائعة

هل أحتاج إلى مكتبة؟

لا. تكفي نقطة نهاية واستدعاء fetch، ويطابق الاستدعاء وثائق Meta تمامًا.

هل يعمل هذا على Vercel أو Lambda؟

نعم، مع التنبيه المعتاد للخوادم عديمة الحالة: أرسل الإقرار أولًا، ثم عالج الطلب عبر قائمة انتظار أو آلية في الخلفية بدلًا من معالجته ضمن الاستدعاء نفسه.

كيف أتحقق من أن الطلب جاء من Meta؟

تحقق من ترويسة التوقيع بمقارنتها مع سر تطبيقك. من المفيد تنفيذ ذلك فور إتاحة نقطة النهاية للعامة.

هل يمكنني استخدام TypeScript؟

نعم. لا يوجد شيء يجب تعريف أنواعه من جانبنا، لأن البيانات الواردة تخص Meta وموثقة من Meta.

تابع القراءة

هل أنت مستعد للبدء؟

أعد إعداد WhatsApp Coexistence خلال دقائق، وليس أشهر. يواصل التطبيق العمل على الهاتف.

ابدأ الفترة التجريبية المجانية

تم التحقق في

إرسال WhatsApp من Node.js