وصّل WhatsApp بـ n8n عبر Cloud API الرسمي

كيف تصل رسالة WhatsApp إلى سير عمل n8n؟

تسلّم Meta كل رسالة تُرسل إلى الرقم إلى عنوان URL واحد تحدده، عبر HTTP POST. ذلك العنوان هو التكامل بأكمله. ضع عقدة Webhook في n8n على عنوان URL مخصص للإنتاج، واضبطه كوجهة webhook للرقم، وسيعمل سير العمل مع كل رسالة واردة.

تحمل الحمولة بيانات المرسل، والنص أو مرجع الوسائط، والطابع الزمني ومعرّف الرسالة. ومن هناك يصبح الأمر سير عمل عاديًا في n8n: فرّع بناءً على المحتوى، وابحث عن العميل، واستدعِ أي خدمات أخرى تستخدمها، ثم قرر ما إذا كنت سترد.

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

{
  "from": "14155550188",
  "id": "wamid.HBgLMTQxNTU1NTAxODgVAgAS",
  "timestamp": "1758412800",
  "type": "text",
  "text": { "body": "do you have anything friday?" }
}

كيف يرسل سير العمل ردًا؟

باستخدام عقدة HTTP Request مقابل Cloud API، مع استخدام phone number id وaccess token الخاصين بالرقم. ويمكن قراءة كليهما من لوحة التحكم أو عبر موصل MCP إذا فضّلت أن يجلبهما مساعد.

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

البنية الموثوقة هي التفريع: تحقق من المدة منذ آخر رسالة واردة، ثم اختر النص الحر أو القالب وفقًا لذلك.

هل يستطيع n8n استخدام موصل MCP أيضًا؟

نعم، وn8n مختلف في هذه النقطة. تتصل عقدة MCP Client Tool فيه بخادم MCP بعيد وتدعم OAuth2، وهو ما يحتاج إليه موصلنا، لذلك تستطيع عقدة AI Agent في سير العمل استدعاء أدواتنا مباشرة.

من المهم معرفة ذلك لأن معظم منصات الأتمتة لا تستطيع هذا. يشغّل Make وZapier خوادم MCP خاصة بهما، ولا يعمل أي منهما كعميل، لذلك لا يستطيع أي منهما الوصول إلى خادم تابع لطرف ثالث. أما n8n فيستطيع.

يفيد هذا في جانب التنفيذ: عقدة وكيل تقرر إرسال رسالة، أو فحص حالة رقم، أو قراءة حالة الموافقة على قالب أثناء تشغيل سير العمل. لكنه لا يستطيع استبدال webhook، لأن MCP لا يملك طريقة لإيقاظه عند وصول رسالة.

أي المسارين ينبغي أن يستخدمهما سير العمل؟

كلاهما، لأن لكل واحد نصفًا مختلفًا، وهذا ليس تفضيلًا.

webhook هو طريقة بدء أي شيء. يكتب العميل، وتسلّم Meta الرسالة إلى عقدة Webhook، ثم يعمل سير العمل. لا يوجد في أي أداة ما يعادل ذلك عبر MCP، لأن البروتوكول يعتمد على الطلب والاستجابة، وليس على شيء يمكن استدعاؤه من الخارج.

تُستخدم أداة MCP Client Tool كي ينفذ وكيل داخل سير العمل إجراءً من دون أن تكتب الاستدعاء يدويًا. إذا كان سير العمل يعرف بالضبط ما سيرسله، فعقدة HTTP Request مقابل Cloud API أبسط وأقل عرضة للخطأ. أما إذا كان الوكيل هو من يقرر، فيمنحه الموصل الأدوات الإحدى عشرة والقواعد الواردة في أوصافها، بما فيها فترة 24 ساعة.

ما الفرق بين هذا وعقد WhatsApp في n8n التي يستخدمها الناس حاليًا؟

تعتمد معظم إعدادات WhatsApp في n8n التي تجدها عادةً على بوابة غير رسمية تسجّل الدخول كجهاز مرتبط. يسهل البدء بها، لكنها تعرّض الرقم للخطر، لأن هذه الآلية تخالف شروط WhatsApp، وتكتشف Meta نمط حركة المرور لا المكتبة المستخدمة.

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

Coexistence هو الجمع الذي كان مفقودًا: API رسمي، مع استمرار عمل الهاتف.

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

• استخدام عنوان URL للاختبار في n8n كوجهة webhook. يتوقف عن الاستماع عند إغلاق المحرر، فتُسلّم الرسائل إلى لا شيء.
• عدم الرد على طلب التحقق من Meta. ترسل Meta طلب GET يتضمن تحديًا قبل تسليم أي شيء، والعقدة التي لا تعيده لا تستقبل أي رسالة.
• الرد بنص حر خارج فترة 24 ساعة. يفشل ذلك بصمت من وجهة نظر سير العمل، ولا يمر إلا قالب تمت الموافقة عليه.

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

تابع القراءة