الرد على رسائل WhatsApp عبر تطبيق Dify

هل تستطيع Meta إرسال رسائل WhatsApp إلى Dify مباشرة؟

ليس بطريقة تُكمل المصافحة. قبل أن تسلّم Meta أي شيء تستدعي الوجهة بطلب GET وتتوقع استرجاع قيمة hub.challenge كجسم استجابة خام. يقبل Webhook Trigger في Dify طريقة HTTP واحدة لكل مشغّل، وتذكر وثائقه أن جسم الاستجابة غير JSON يُحوَّل تلقائيًا إلى JSON، فيعود OK ككائن رسالة. لا يمكن إذن ترديد التحدي كما هو، ولا تبدأ Meta التسليم أبدًا.

لذلك يوضع شيء صغير في المقدمة. عقدة Webhook في n8n أو مسار بلغة Python أو Node أو دالة serverless تجيب عن GET وتقبل POST وتسلّم النص إلى Dify. وفي هذا المستقبل أيضًا يُفحص السر العشوائي الطويل في عنوان URL الخاص بـ webhook، لأن ترويسة X-Hub-Signature-256 تُوقَّع بسر تطبيق Tech Provider ولا يستطيع العميل التحقق منها.

كيف يتحدث المستقبل مع تطبيق Dify؟

باستدعاء واحد إلى Service API في Dify: POST /chat-messages، مع مصادقة بمفتاح API الخاص بالتطبيق. يحمل الجسم query وهو نص العميل، وuser وهو معرّف تحدده أنت. استخدم رقم WhatsApp الخاص بالمرسل قيمةً لـ user، واحتفظ بقيمة conversation_id التي يعيدها Dify لتكمل الرسالة التالية من الشخص نفسه المحادثة ذاتها.

يهم response_mode. يعيد blocking النتيجة بعد اكتمال الرد، وتحذّر وثائق Dify من أن التوليد الطويل على Dify Cloud قد يقطعه وكيل الحافة. أما تطبيقات Agent فتدعم streaming فقط، ويفشل معها طلب blocking بالخطأ 400. الشكل المتين هو مستقبل يقرأ البث ويرسل رسالة WhatsApp واحدة في النهاية.

ثم يخرج الرد رسالة نصية عبر Cloud API إلى الرقم نفسه، وهي مجانية داخل نافذة 24 ساعة التي فتحتها رسالة العميل.

ماذا يضيف خادم MCP داخل Dify؟

قدرة وكيل Dify على التصرف على الرقم دون أن تربط كل استدعاء بنفسك. يتصل Dify بخوادم MCP عبر HTTP، ويسجّل نفسه لديها افتراضيًا عبر التسجيل الديناميكي للعميل في OAuth، وهذا ما يدعمه خادم MCP الخاص بـ EasyCoexistence. أضفه ضمن Tools وسجّل الدخول مرة واحدة، فيحصل الوكيل على الأدوات: عرض الأرقام، فحص صحة رقم، إرسال رسالة، إرسال قالب معتمد، قراءة حالة القالب.

هذا هو المكان المناسب للعمل الاستباقي: سير عمل في Dify يتابع العميل في اليوم التالي يجب أن يستخدم send_template، لأن النص الحر خارج النافذة يعيد الخطأ 131047، وأوصاف الأدوات تقول ذلك للنموذج.

أما ما لا يستطيعه MCP فهو إيقاظ Dify حين يكتب عميل. البروتوكول طلب واستجابة، فتظل الرسائل الواردة تصل عبر webhook والمستقبل الذي في المقدمة.

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

• استخدام عنوان URL لـ Webhook Trigger في Dify وجهةً لـ webhook. يعود التحدي مغلّفًا بـ JSON ولا تتحقق Meta من نقطة النهاية (endpoint) أبدًا.
• إرسال طلب blocking إلى تطبيق Dify من نوع Agent. تدعم تطبيقات Agent البث فقط، ويفشل الاستدعاء بالخطأ 400.
• استخدام قيمة user جديدة مع كل رسالة. يحصر Dify المحادثات بـ user، فتبدأ كل رسالة محادثة جديدة بلا ذاكرة.

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

تابع القراءة