חיבור WhatsApp ל-n8n באמצעות ה-Cloud API הרשמי

איך מגיעה הודעת WhatsApp לזרימת עבודה ב-n8n?

Meta שולחת כל הודעה שנשלחת למספר לכתובת URL יחידה שבוחרים, באמצעות בקשת HTTP POST. הכתובת הזו היא כל האינטגרציה. מציבים צומת וובהוק של n8n בכתובת URL של ייצור, מגדירים אותה כיעד הוובהוק של המספר, וזרימת העבודה מופעלת בכל הודעה נכנסת.

ה-payload כולל את השולח, את הטקסט או הפניה למדיה, חותמת זמן ואת מזהה ההודעה. מכאן זו זרימת עבודה רגילה ב-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 יכולה.

המחבר מתאים לחלק של הפעולה: צומת סוכן שמחליט לשלוח הודעה, לבדוק את תקינות החיבור של מספר או לקרוא את סטטוס האישור של תבנית בזמן שזרימת העבודה פועלת. הוא לא יכול להחליף את הוובהוק, כי ל-MCP אין דרך להתעורר בעקבות הודעה נכנסת.

באיזה משני המסלולים כדאי להשתמש בזרימת עבודה?

בשניהם, עבור שני חלקים שונים, והחלוקה הזו אינה עניין של העדפה.

הוובהוק הוא הדרך שבה הכול מתחיל. לקוח כותב, Meta שולחת לצומת הוובהוק שלכם, וזרימת העבודה מופעלת. אין מקבילה של MCP לכך באף כלי, כי הפרוטוקול מבוסס על בקשה ותגובה ולא על משהו שאפשר לקרוא לו מבחוץ.

MCP Client Tool מיועד לסוכן בתוך זרימת העבודה, כדי שיפעל בלי שתצטרכו לקודד את הקריאה ידנית. אם זרימת העבודה כבר יודעת בדיוק מה לשלוח, צומת HTTP Request מול ה-Cloud API פשוט יותר ומשאיר פחות מקום לתקלות. אם סוכן מקבל את ההחלטה, המחבר נותן לו את אחד עשר הכלים ואת הכללים שמגיעים עם התיאורים שלהם, כולל חלון 24 השעות.

מה שונה כאן מצומתי WhatsApp של n8n שאנשים כבר משתמשים בהם?

רוב הגדרות WhatsApp של n8n שתמצאו בפועל מבוססות על שער לא רשמי שמתחבר כמכשיר מקושר. קל להתחיל איתן, אבל הן מסכנות את המספר, כי המנגנון מפר את התנאים של WhatsApp ו-Meta מזהה את דפוס התעבורה ולא את הספרייה.

המסלול הנפוץ האחר הוא ה-API הרשמי בלי Coexistence. הוא עובד, אבל מעביר את המספר. אפליקציית WhatsApp Business מפסיקה לפעול בו, והצוות שענה לאורך כל היום צריך לעבור לכלי חדש. עבור רוב העסקים הקטנים זו לא אפשרות מעשית, ולכן רבים מהם הגיעו מלכתחילה לשערים לא רשמיים.

Coexistence הוא השילוב שהיה חסר: API רשמי, והטלפון ממשיך לעבוד.

טעויות נפוצות

• שימוש בכתובת URL לבדיקה של n8n כיעד הוובהוק. היא מפסיקה להאזין כשהעורך נסגר, ולכן ההודעות נשלחות לשום מקום.
• אי-מענה לבקשת האימות של Meta. Meta שולחת GET עם אתגר לפני שהיא שולחת דבר, וצומת שלא מחזיר אותו לעולם לא מקבל הודעה.
• מענה בטקסט חופשי מחוץ לחלון של 24 שעות. מנקודת המבט של זרימת העבודה זה נכשל בשקט, ורק תבנית מאושרת נשלחת.

שאלות נפוצות

המשיכו לקרוא