אפליקציית Dify שעונה להודעות ב-WhatsApp
מפנים את הוובהוק (Webhook) של המספר אל מקלט קטן, למשל תהליך ב-n8n או נתיב בקוד שלכם, שמעביר כל הודעה ל-API של Dify לשליחת הודעת צ'אט ומחזיר את התשובה דרך Cloud API. בתוך Dify אפשר להוסיף את שרת MCP של EasyCoexistence ככלי, כדי שהסוכן יפעל על המספר בעצמו.
Webhook Trigger של Dify עוטף גוף תגובה שאינו JSON ב-JSON, ולכן אינו יכול להחזיר את ה-challenge הגולמי של Meta.
קריאת Service API של Dify ששולחת הודעת משתמש אחת לאפליקציית צ'אט ומחזירה את התשובה שלה.
כלי MCP של Dify מקבלים פרטי OAuth דרך רישום לקוח דינמי, והאפשרות פעילה כברירת מחדל.
האם Meta יכולה לשלוח הודעות WhatsApp ישירות ל-Dify?
לא באופן שמשלים את לחיצת היד. לפני ש-Meta מוסרת משהו, היא קוראת ליעד בבקשת GET ומצפה לקבל את הערך hub.challenge כגוף תגובה גולמי. Webhook Trigger של Dify מקבל שיטת HTTP אחת לכל טריגר, והתיעוד שלו קובע שגוף תגובה שאינו JSON מומר אוטומטית ל-JSON, כך ש-OK חוזר כאובייקט הודעה. את ה-challenge אי אפשר להחזיר במדויק, ו-Meta אף פעם לא מתחילה למסור.
לכן צריך משהו קטן מלפנים. צומת Webhook ב-n8n, נתיב ב-Python או ב-Node, או פונקציית serverless עונים ל-GET, מקבלים את ה-POST ומעבירים את הטקסט ל-Dify. המקלט הזה הוא גם המקום שבו נבדק הסוד האקראי הארוך שבכתובת ה-URL של הוובהוק, כי הכותרת 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 Trigger של Dify כיעד הוובהוק. ה-challenge חוזר עטוף ב-JSON ו-Meta אף פעם לא מאמתת את נקודת הקצה.
- שליחת בקשת blocking לאפליקציית Agent של Dify. אפליקציות Agent תומכות ב-streaming בלבד, והקריאה נכשלת עם 400.
- שימוש בערך user חדש בכל הודעה. Dify מצמידה שיחות ל-user, ולכן כל הודעה פותחת שיחה חדשה בלי זיכרון.
מחברים את המספר ב-easycoexistence.com, מפנים את יעד הוובהוק אל המקלט שלכם, ומוסיפים את שרת MCP ל-Dify בשביל הפעולות של הסוכן. החל מ-US$ 9 למספר מחובר בחודש, יורד ל-US$ 1 ככל שמוסיפים מספרים, ו-3 הימים הראשונים ללא תשלום.
שאלות נפוצות
האם ל-Dify יש ערוץ WhatsApp?
לא בתיעוד שלה. אפליקציית Dify נגישה דרך ה-Service API שלה, ולכן WhatsApp מתחבר דרך מקלט שקורא ל-API הזה.
האם n8n יכול להיות המקלט?
כן. צומת Webhook מקבל, צומת HTTP Request קורא ל-Dify, וצומת HTTP Request שני שולח דרך Cloud API את התשובה.
האם הצוות יכול להמשיך לענות מהטלפון?
כן. Coexistence משאיר את אפליקציית WhatsApp Business פעילה במספר, ותשובות שנשלחות מהטלפון מגיעות כאירועי echo אל המקלט.
האם EasyCoexistence רואה את השיחה?
לא. Meta מוסרת ישירות למקלט שלכם, ותוכן ההודעות לא נשמר אצלנו. שרת MCP קורא את מצב החשבון והמספר.
המשיכו לקרוא
מוכנים להתחיל?
מגדירים WhatsApp Coexistence בתוך דקות, לא חודשים. האפליקציה ממשיכה לעבוד בטלפון.
התחילו תקופת ניסיון בחינםנבדק ב-