Webhooks במאמבל: המדריך המלא לארבע נקודות החיבור למערכות חיצוניות

תקציר

Webhook הוא מנגנון שמאפשר למאמבל לדחוף אירועים בזמן אמת למערכות חיצוניות (CRM, BI, מערכת ניהול הזמנות, מערכת תיוט). במקום שהמערכת שלכם תצטרך לשאול את מאמבל “מה קרה?”, מאמבל שולחת לכם הודעה ברגע שהאירוע מתרחש. במאמר תכירו את ארבעת ה‑Webhooks השונים שמאמבל מציעה, את ההבדל ביניהם, ואיך לבחור את הנכון לכל מקרה. אם אתם רוצים לחבר את WhatsApp שלכם למערכות אחרות בעסק, זה המאמר שצריך להבין לפני שיוצאים לדרך.

מה זה Webhook

Webhook הוא בקשת HTTP (בדרך כלל POST) שמאמבל שולחת לכתובת URL שאתם נותנים לה, ברגע שמתרחש אירוע מסוים. הנתונים של האירוע מועברים בגוף הבקשה כ‑JSON, והמערכת שלכם יכולה לעבד אותם ולפעול בהתאם.

דוגמה פשוטה:

1. לקוח שולח הודעה ב‑WhatsApp.
2. מאמבל מקבלת את ההודעה ומציגה אותה בצ’אט.
3. במקביל, מאמבל שולחת POST לכתובת שהגדרתם, עם פרטי ההודעה ב‑JSON.
4. המערכת שלכם (CRM, מערכת תמיכה, מסד נתונים) מקבלת את הנתונים ויכולה לפעול: ליצור tickets, לעדכן רשומה, להפעיל אוטומציה משלכם.

היתרון העיקרי: אין צורך בפולינג. המערכת שלכם לא צריכה לשאול את מאמבל כל דקה “האם יש משהו חדש?”. האירוע נדחף אליה ברגע שהוא קורה.

ארבעת ה‑Webhooks של מאמבל

מאמבל מציעה ארבע נקודות חיבור שונות למערכות חיצוניות, כל אחת לתרחיש אחר. הבחירה הנכונה תלויה במה אתם רוצים לדעת ומתי.

בהמשך, סעיף ייעודי לכל אחד מהם.

1. Webhook חשבוני להודעות נכנסות

זה ה‑Webhook הרחב ביותר. מאמבל שולחת אותו על כל הודעה שמגיעה מלקוח לחשבון שלכם, ללא תנאים נוספים.

איפה להגדיר

בהגדרות החשבון, תחת הגדרות → פרופיל טכני → העבר הודעה אל Webhook. שדה אחד בלבד: ה‑URL שאליו מאמבל תשלח את הבקשות.

מה בתוך ה‑Payload

בכל הודעה נכנסת, מאמבל שולחת JSON עם:

• פרטי הלקוח (שם, טלפון, מזהה לקוח).
• תוכן ההודעה (טקסט או רפרנס למדיה).
• סוג ההודעה (טקסט, תמונה, קובץ, אודיו, וידאו).
• מטא‑דאטה של השיחה (מזהה השיחה, סטטוס, תווית).
• חתימת זמן (timestamp).

מה ה‑Webhook הזה לא כולל

חשוב לדעת מה הוא לא שולח, כדי לא להסתמך עליו לדברים שלא במנדט שלו:

• סטטוס מסירה (delivered, read, failed) של הודעות יוצאות. אם אתם רוצים לדעת אם הודעה שלכם הגיעה, צריך Webhook של אוטומציה.
• שינויי סטטוס שיחה (חדשה ← בטיפול ← סגורה). גם זה אוטומציה.
• הוספת תוויות או הסרתן.
• אירועים פנימיים של מאמבל כמו ציוות סוכן, פתיחה ידנית של שיחה.

מתי להשתמש

השתמשו ב‑Webhook הזה כשאתם רוצים להעביר את כל ההודעות הנכנסות למערכת חיצונית, לדוגמה:

• שמירה מקבילה ב‑CRM לכל אינטראקציה.
• עיבוד בינה מלאכותית של ההודעות בזמן אמת מצידכם.
• מילוי tickets במערכת תמיכה.
• שכפול ההודעות ל‑BI ולניתוחים.

2. Webhook באוטומציה

זה ה‑Webhook הגמיש ביותר. במנוע ה‑אוטומציות, אחת הפעולות האפשריות היא שלח Webhook. אתם בונים אוטומציה עם טריגר ותנאים, וכשהיא רצה, היא שולחת בקשת HTTP בדיוק לפי המפרט שלכם.

איפה להגדיר

בעמוד אוטומציות, יוצרים אוטומציה חדשה. מגדירים טריגר (לדוגמה, “סטטוס שיחה השתנה”) ותנאים (לדוגמה, “לסטטוס = סגורה”). בחלק הפעולות, בוחרים שלח Webhook, וזה פותח שני שדות: URL ו‑Payload.

מבנה ה‑Payload שאתם בונים

בניגוד ל‑Webhook החשבוני שמשלח Payload קבוע, כאן אתם בונים את ה‑Payload בדיוק כפי שצריך. כל שורה כוללת:

• מפתח (Key). שם השדה ב‑JSON, טקסט חופשי.
• ערך (Value). או טקסט קבוע, או משתנה מערכת (שם הלקוח, סטטוס השיחה, מזהה הקמפיין).

זה אומר שאם המערכת שלכם דורשת JSON במבנה { "phone": "...", "event": "closed", "label": "..." }, אתם בונים את זה בדיוק. הגמישות הזו מאפשרת חיבור לכל מערכת חיצונית בלי שצריך מתאם (adapter) באמצע.

טריגרים נפוצים שמובילים ל‑Webhook

• סטטוס שיחה השתנה לסגורה → סנכרון של תוצאת השיחה ל‑CRM.
• לקוח הוצמד לרשימה “ליד חם” → התראה לצוות מכירות במערכת חיצונית.
• שיחה לא פעילה למשך X שעות → התראה למנהל לבדיקה.
• סוכן ביצע שיוך עצמי → רישום חישובי בונוס במערכת השכר.

מתי להשתמש

זה ה‑Webhook המומלץ לרוב המקרים. השתמשו בו כשאתם רוצים לקבל התראה על אירוע ספציפי, לא על כל הודעה. ראו אוטומציות במאמבל, המדריך המלא.

3. צומת HTTP בקנבס הצ’אטבוט

בתוך זרימת צ’אטבוט, אפשר להוסיף צומת מסוג HTTP בקשת. הצומת הזה שולח בקשה למערכת חיצונית כשהצ’אט מגיע אליו, ויכול לקבל בחזרה תשובה ולהשתמש בה בהמשך השיחה.

מה זה מאפשר

בניגוד לשני ה‑Webhooks הקודמים שהם חד‑כיווניים (מאמבל שולחת ולא מחכה לתשובה משמעותית), הצומת הזה הוא דו‑כיווני: הוא שולח, מחכה לתשובה, ומשתמש בה.

דוגמאות:

• שליפת סטטוס הזמנה. הצ’אט מבקש מספר הזמנה, שולח אותו למערכת ה‑e‑commerce, ומקבל חזרה את הסטטוס שמוצג ללקוח.
• בדיקת זמינות פגישה. הצ’אט מציע ללקוח לראות פגישות פנויות, שולח את הבקשה ליומן, ומקבל רשימת זמנים.
• אימות פרטי לקוח. הצ’אט מבקש מספר תעודת זהות ובודק במערכת הפנימית שלכם אם הלקוח רשום.

מתי להשתמש

השתמשו בצומת HTTP כשהצ’אטבוט צריך נתונים שלא נמצאים במאמבל, או כשאתם רוצים לבצע פעולה במערכת חיצונית כחלק מזרימת השיחה. ראו בניית צ’אטבוט במאמבל.

4. פעולת HTTP ב‑Dolores AI

בסוכן Dolores AI, אחת מהפעולות שאפשר להגדיר היא שליחת בקשת HTTP. ההבדל מצומת HTTP בצ’אטבוט: כאן Dolores מחליטה מתי להפעיל, על סמך תיאור שאתם נותנים לה.

איך זה עובד

אתם מגדירים פעולה עם:

1. תיאור בשפה פשוטה: “מתי Dolores צריכה לעשות את זה?”. לדוגמה: “כשהלקוח אומר שהוא רוצה לבטל מנוי”.
2. פעולה: שליחת בקשת HTTP, עם URL ו‑Payload.

במהלך השיחה, Dolores מנתחת את הקשר ומחליטה אם להפעיל את הפעולה. אם השיחה מתאימה לתיאור, הפעולה מתבצעת אוטומטית.

מתי להשתמש

השתמשו ב‑Dolores HTTP action כשהטריגר לפעולה הוא שיפוטי ולא ברור מראש. אם אתם יכולים לכתוב כלל ברור (“כשהסטטוס השתנה לסגורה”), עדיפה אוטומציה. אם הטריגר הוא משהו שצריך הבנת הקשר (“כשנראה שהלקוח מבולבל ורוצה לדבר עם נציג”), Dolores היא הכלי הנכון. ראו Dolores AI, המדריך להתחלת עבודה.

איך לבחור את ה‑Webhook הנכון

שאלו את עצמכם:

• אם אתם רוצים כל הודעה נכנסת: Webhook חשבוני.
• אם אתם רוצים אירוע ספציפי שאפשר להגדיר בכללים: Webhook באוטומציה.
• אם אתם רוצים לקרוא למערכת חיצונית בנקודה מוגדרת בצ’אט: צומת HTTP בקנבס.
• אם הטריגר הוא שיפוטי וצריך AI להבין: פעולת HTTP ב‑Dolores.

אפשר וגם רצוי לשלב כמה. דוגמה ריאלית: עסק יכול להגדיר את כולם בו זמנית. Webhook חשבוני יזרים את כל ההודעות ל‑BI. אוטומציות יסנכרנו אירועי שיחה ל‑CRM. צ’אטבוט ישלוף סטטוס הזמנה בזמן השיחה. Dolores תפעיל פעולות כשנדרש שיקול דעת.

נושאים שכדאי להכיר

אבטחה

ה‑Webhook שולח נתוני לקוחות לכתובת URL. וודאו:

• שה‑URL הוא HTTPS (לא HTTP). בלי הצפנה, הנתונים חשופים בדרך.
• שהמערכת המקבלת מאמתת את הבקשה. לדוגמה, באמצעות מפתח סוד שמוסיפים ל‑Payload ושבודקים בצד המקבל. כל מי שמכיר את ה‑URL יכול לזייף בקשות אם אין אימות.
• שלא מעבירים מידע רגיש בלי צורך. אם המערכת המקבלת לא צריכה את המספר המלא של הלקוח, אל תשלחו אותו.

אמינות

Webhooks יכולים להיכשל. סיבות נפוצות: המערכת המקבלת לא זמינה רגעית, חיבור אינטרנט נופל, ה‑URL השתנה. תכננו עם זה בחשבון:

• אל תסמכו רק על Webhook לפעולות חיוניות. הוסיפו סנכרון תקופתי כגיבוי.
• מעקב במערכת המקבלת: סעו על “כמה בקשות צפויות לעומת כמה התקבלו”.
• בדיקה ידנית פעם בשבוע: אם משהו נראה לא נכון, ראו את הסעיף הבא.

אין יומן ב‑Mumble

מאמבל לא שומרת יומן של Webhooks שנשלחו. אתם לא יכולים לחזור ולראות “מה נשלח אתמול ב‑3 בצהריים”. הדיבאג חייב להיעשות מהצד המקבל (לוגים של ה‑URL שמקבל את הבקשות). זה מקום שכדאי לדעת עליו מראש.

שיטות עבודה מומלצות

• בדיקה לפני פרודקשן. השתמשו בשירות כמו webhook.site או requestbin.com לבדיקה ראשונית. שולחים אליהם את ה‑Webhook ורואים בדיוק מה מאמבל שולחת. אחרי שמרגישים בטוחים, מחליפים לכתובת האמיתית.
• הוסיפו מפתח אימות. בכל Webhook באוטומציה, הוסיפו שדה secret או token עם ערך מוסכם, וודאו שצד המקבל מאמת אותו לפני שעובד עם הנתונים.
• תכננו ל‑idempotency. אם אותו Webhook יישלח פעמיים בטעות (נדיר אבל אפשרי), צד המקבל צריך לזהות זאת ולא לבצע פעולה כפולה. הוסיפו מזהה ייחודי לכל אירוע (לדוגמה, מזהה השיחה ביחד עם זמן האירוע).
• שמרו את ה‑Webhook URL סודי. כל מי שמכיר את ה‑URL יכול לשלוח אליו בקשות מזויפות. אל תפרסמו אותו פומבית.
• תיעוד פנימי. תעדו אילו Webhooks אתם מפעילים, איזה Payload כל אחד שולח, ולאן הוא הולך. בעוד חודשיים, כשמשהו נשבר, התיעוד הוא ההבדל בין דקה של תיקון לבין יום של חיפוש.
• בדקו זמני תגובה. אם המערכת המקבלת איטית להגיב (יותר מ‑3‑5 שניות), Webhook יכול להיכשל. וודאו שהיא ערוכה לעבד בקשות במהירות.

בעיות נפוצות

ה‑Webhook לא מגיע למערכת שלי

בדקו לפי הסדר:

1. ה‑URL נכון ופועל? נסו לבדוק אותו עם curl או Postman מבחוץ.
2. ה‑URL ב‑HTTPS? Webhooks ל‑HTTP לפעמים נחסמים.
3. אם זה Webhook באוטומציה: האם האוטומציה אכן מופעלת? האם הטריגר באמת קורה?
4. אם זה Webhook חשבוני: האם הוא הוגדר ב‑הגדרות → פרופיל טכני?
5. האם יש חומת אש או הגבלת IP שחוסמת בקשות מ‑Mumble?

אם הכל תקין ועדיין לא מגיע, פנו לתמיכת מאמבל עם דוגמה ספציפית.

ה‑Webhook מגיע אבל הפורמט לא מה שהמערכת שלי מצפה

זה תלוי בסוג ה‑Webhook:

• Webhook חשבוני: הפורמט קבוע על ידי מאמבל. צריך להתאים את המערכת המקבלת.
• Webhook באוטומציה: אתם בונים את ה‑Payload. ערכו את שדות המפתח/ערך באוטומציה כדי שיתאימו למה שצריך.

אני רוצה Webhook לסטטוס מסירה (delivered/read/failed)

הדרך: צרו אוטומציה עם טריגר על שינוי סטטוס הודעה, ופעולה של Webhook. שימו לב שהטריגרים הזמינים תלויים בגרסת מאמבל; ייתכן שדורש פיצ’ר מסוים.

ה‑Webhook עובד לפעמים ולפעמים לא

סיבות אפשריות:

• המערכת המקבלת לא יציבה. בדקו את ה‑uptime שלה.
• מגבלת קצב בצד המקבל. אם יש פתאום הרבה אירועים, אולי הוא דוחה חלק מהבקשות.
• שינוי ב‑URL או בהגדרות שלא תועדו.

בדקו את הלוגים בצד המקבל. אם אין שם רישום של הבקשות שלא הגיעו, הבעיה כנראה ברשת בין מאמבל למערכת שלכם.

ה‑Webhook מקבל בקשות מזויפות מתוקפים

אם פרסמתם את ה‑URL בטעות או אם הוא ניתן לניחוש, יכול להיות שמישהו שולח אליו בקשות מזויפות. הוסיפו מפתח אימות סודי לכל בקשה ב‑Payload, ובדקו אותו לפני עיבוד הנתונים. תוקף שלא יודע את המפתח לא יוכל לזייף.

אני רוצה Webhook דו‑כיווני (לדוגמה, לתת לי תשובה שהבוט ישתמש בה)

זה לא אפשרי ב‑Webhook באוטומציה (שהוא חד‑כיווני). אבל זה אפשרי בצומת HTTP בקנבס הצ’אטבוט, שמחכה לתשובה ומשתמש בה בהמשך הזרימה.

קישורים קשורים

• אוטומציות במאמבל, המדריך המלא
• בניית צ’אטבוט במאמבל
• Dolores AI, המדריך להתחלת עבודה
• Mumble API, המדריך המלא
• חיבור Mumble ל‑Make
• הגדרות חשבון כלליות

שורה תחתונה

Webhooks הם הגשר בין מאמבל למערכות החיצוניות שלכם. בחירת ה‑Webhook הנכון תלויה במה אתם רוצים לדעת: כל הודעה, אירוע ספציפי, נקודה בצ’אט, או החלטה של AI. רוב הצרכים מתממשים באוטומציות עם Webhook, וזו נקודת ההתחלה הטובה ביותר. כשעובדים עם Webhooks, הקפידו על HTTPS, אימות, וגיבוי לאמינות. שעה של תכנון נכון חוסכת שבועות של דיבאג.