الرد على رسائل WhatsApp عبر chatflow في Flowise

لماذا يحتاج Flowise إلى طبقة أمامه؟

لأن webhook في Meta وواجهة برمجة التطبيقات (API) في Flowise يستخدمان بنيتين مختلفتين. تتحقق Meta من الوجهة بطلب GET يجب أن يعيد hub.challenge كما هو في نص الاستجابة الخام، ثم تسلّم كل رسالة بطلب POST يحمل JSON متداخلًا. أما Prediction API في Flowise فتتوقع طلب POST إلى /api/v1/prediction/ يليه معرّف التدفق، مع الحقل question. لا يتكيف أي منهما مع الآخر، لذلك يتولى مستقبِل الترجمة بينهما.

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

كيف ينبغي أن يستدعي المستقبِل Prediction API؟

بنص العميل في الحقل question، ورقم WhatsApp الخاص بالعميل معرّفًا للجلسة. يقبل Flowise القيمة overrideConfig مع كل طلب، وsessionId بداخلها هو ما يتيح لعقد الذاكرة الاحتفاظ بمحادثة واحدة لكل شخص بدلًا من خلط الجميع في سلسلة واحدة. ورقم المرسل في حمولة webhook مفتاح ثابت وطبيعي لذلك.

إذا كان chatflow محميًا بمفتاح API، يرسله المستقبِل بوصفه bearer token. اضبط streaming على false ما لم يكن المستقبِل مبنيًا لتجميع البث، لأن WhatsApp يسلّم رسالة كاملة واحدة لا رمزًا بعد رمز.

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

POST https://your-flowise-host/api/v1/prediction/<flow-id>
Authorization: Bearer <flowise-api-key>
Content-Type: application/json

{
  "question": "do you have anything friday?",
  "streaming": false,
  "overrideConfig": { "sessionId": "14155550188" }
}

هل يمكن لوكيل Flowise استخدام خادم MCP الخاص بـ EasyCoexistence؟

ليس اليوم. يتصل Custom MCP في Flowise بخادم Streamable HTTP عبر عنوان URL ومجموعة رؤوس، وعادةً token ثابت من نوع bearer محفوظ في متغير داخل Flowise. أما خادم MCP الخاص بـ EasyCoexistence فيعتمد المصادقة عبر OAuth، بتسجيل دخول من المتصفح ورموز يصدرها بنفسه، فلا يوجد مفتاح ثابت يوضع في ترويسة.

الحل العملي هو أن يقرر التدفق ويتولى المستقبِل الإرسال. يعيد التدفق النص المطلوب قوله، أو اسم القالب عندما يصمت العميل أكثر من يوم، ثم ينفذ المستقبِل استدعاء Cloud API باستخدام token الرقم. وبذلك لا يقيم token داخل Flowise أبدًا، ويُفرض شرط 24 ساعة في الكود بفحص وقت آخر رسالة كتبتها جهة الاتصال، بدلًا من تركه لنموذج قد ينساه.

وتصل الرسائل الواردة عبر webhook فقط، مهما كانت طريقة الإرسال.

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

• إغفال sessionId. حينها يتشارك كل العملاء ذاكرة واحدة، وقد تظهر تفاصيل شخص في رد موجه إلى شخص آخر.
• انتظار Flowise قبل الرد على Meta. الرد 200 البطيء يُعاد إرساله، فتُعالَج الرسالة نفسها مرتين.
• ترك التدفق يرسل نصًا حرًا بعد يوم. خارج النافذة ترفضه Meta مع الخطأ 131047.

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

تابع القراءة