מה זה Webhook?

מה זה בעצם Webhook

המילה Webhook מורכבת משתי מילים באנגלית: Web — אינטרנט, ו-Hook — וו או "נקודת תפיסה". הרעיון פשוט: אתם נותנים למרכזייה כתובת באינטרנט, והיא מתחייבת "לדפוק בדלת" של הכתובת הזאת בכל פעם שקורה אירוע שביקשתם לדעת עליו.

אפשר לחשוב על זה כמו על שליח שמביא מכתב. במקום שתצאו לתיבת הדואר כל חמש דקות ותבדקו אם הגיע משהו, השליח מצלצל בדלת ברגע שיש מכתב. המכתב הוא "פרטי האירוע" — למשל איזה מספר התקשר, לאיזה קו, ומתי. הדלת היא השרת שלכם, או מערכת כמו CRM, שמקבלת את ההודעה ועושה איתה משהו.

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

איך זה עובד — צעד אחר צעד

1. מגדירים כתובת. מישהו אצלכם (מתכנת, ספק ה-CRM, או אנחנו) מכין כתובת באינטרנט שיודעת לקבל הודעות — למשל כתובת בשרת של מערכת ההזמנות שלכם.
2. מחברים אותה לאירוע. במרכזייה קובעים מתי לקרוא לכתובת: כששיחה נכנסת לקו מסוים, כשהיא מגיעה לנקודה מסוימת במסלול, וכדומה.
3. האירוע קורה. לקוח מתקשר. ברגע הזה המרכזייה שולחת בקשה לכתובת, ובתוכה פרטים — מספר המתקשר, מזהה השיחה, הקו שאליו חייג.
4. השרת שלכם מעבד. הוא מחפש את המספר ברשימת הלקוחות, פותח כרטיס, רושם את השיחה או שולח הודעה לנציג.
5. השרת עונה. תשובה קצרה חוזרת למרכזייה. במקרים מסוימים התשובה אפילו משפיעה על המשך השיחה — למשל לאן להעביר אותה.

כל זה לוקח בדרך כלל שבריר שנייה. הנציג יכול לראות את הכרטיס של הלקוח עוד לפני שהרים את השפופרת.

מה יש בתוך ההודעה

ההודעה שהמרכזייה שולחת היא בקשת אינטרנט רגילה, בדרך כלל מסוג POST, ובתוכה שדות עם ערכים — כמו טופס באתר שמתמלא אוטומטית. שדות נפוצים במערכות טלפוניה: מספר המתקשר, המספר שאליו חייג, מזהה ייחודי של השיחה, שעה, ולעיתים גם הנקודה במסלול שבה השיחה נמצאת.

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

גם התשובה של השרת שלכם היא חלק מהחוזה. יש מערכות שמסתפקות ב"קיבלתי", ויש מערכות שבהן התשובה אומרת למרכזייה מה לעשות הלאה — לאיזה תפריט להמשיך או לאיזה נציג לחבר. לכן חשוב לדעת מראש באיזה פורמט בדיוק צריך לענות.

Webhook מול API — מי שואל את מי

הדרך השנייה לחבר מערכות היא API. ההבדל הוא בכיוון: ב-API המערכת שלכם פונה למרכזייה ושואלת "מה חדש?". ב-Webhook המרכזייה פונה אליכם ומספרת. לשיטה הראשונה קוראים "משיכה" (Polling), לשנייה "דחיפה" (Push).

בפועל, מערכות טובות משלבות את שתיהן. ה-Webhook מודיע "שיחה חדשה מהמספר הזה", ואחרי שהשיחה מסתיימת המערכת פונה ב-API כדי למשוך את כרטיס השיחה המלא: משך, מי ענה, הקלטה.

דוגמאות מהחיים

• חנות בבני ברק: כשלקוח מתקשר, מערכת ההזמנות מקבלת את המספר ומציגה לנציג את ההזמנה האחרונה שלו. הנציג עונה "שלום, לגבי ההזמנה מאתמול?"
• ישיבה עם פנימייה: כל שיחה לקו ההורים נרשמת אוטומטית בגיליון, כך שהמשגיח רואה מי התקשר ובאיזו שעה.
• עמותה בערב התרמה: כל שיחה שנכנסת לקו התרומות מעדכנת מונה על מסך בחדר, והמתנדבים רואים את ההתקדמות בזמן אמת.
• מוקד שירות: שיחה שלא נענתה פותחת משימה "לחזור ללקוח" במערכת הניהול, עם שם הלקוח ושעת השיחה.
• מערכת תורים לרופא או ליועץ: המתקשר מזוהה, והמערכת מחליטה לפי הרשומה שלו לאיזה נציג לנתב אותו.

מה חשוב לבדוק לפני שמחברים

• השרת חייב לענות מהר. המרכזייה מחכה לתשובה בזמן שהשיחה ממתינה. שרת איטי פירושו מתקשר שמחכה בשקט. את העבודה הכבדה עדיף לעשות אחרי שעונים.
• תשובה ישירה, בלי הפניות. מערכות טלפוניה רבות לא "הולכות אחרי" הפניה לכתובת אחרת (Redirect), מטעמי אבטחה. הכתובת צריכה להיות הכתובת הסופית ולענות ישירות.
• לדעת מה קורה כשהשרת נופל. מה יקבל המתקשר אם הכתובת לא עונה? כדאי לתכנן מסלול גיבוי, כדי שהשיחה תמשיך גם אם המערכת החיצונית לא זמינה.
• אבטחה. הכתובת פתוחה לאינטרנט, ולכן כדאי לוודא שהיא מקבלת רק בקשות אמיתיות ולא חושפת מידע למי שסתם ניחש אותה.
• לבדוק עם שיחה אמיתית. לפני שמחברים את הקו הראשי, מנסים על מספר צדדי ומוודאים שהפרטים מגיעים בדיוק בפורמט שהמערכת מצפה לו.

יתרונות ומגבלות

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

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

שלושה חיבורים מהחיים, צעד אחר צעד

1. כרטיס לקוח שקופץ במרפאה. מרפאה עם מערכת תורים משלה. ה-Webhook מחובר לנקודה במסלול שבה השיחה מגיעה למזכירות. כשלקוח מתקשר, המרכזייה שולחת למערכת התורים: מספר המתקשר, מזהה השיחה, השעה. השרת של מערכת התורים מחפש את המספר, מוצא את הכרטיס, ומציג על המסך של המזכירה חלון: השם, התור הבא, הערות. הוא עונה למרכזייה "קיבלתי" תוך פחות משנייה, והשיחה ממשיכה לצלצל. אם המספר לא נמצא — נפתח חלון "לקוח חדש" עם המספר כבר מוקלד. אם השרת של המרפאה נפל — המרכזייה לא מחכה לו; השיחה מצלצלת כרגיל, רק בלי החלון.

2. שיחה שלא נענתה הופכת למשימה. מוקד שירות של חברת מזגנים. Webhook על סיום שיחה בתור השירות. כשהשיחה מסתיימת, המרכזייה שולחת את מזהה השיחה ואת מה שידוע: המספר, כמה המתין, האם נענה. אם לא נענה, השרת של מערכת הניהול פותח משימה "לחזור ל-052-XXXXXXX, המתין 3 דקות" ומקצה אותה לנציג הפנוי. במקביל יוצאת הודעת SMS ללקוח: "ראינו שהתקשרתם, נחזור אליכם בתוך שעה". חצי שעה אחרי, כשההקלטה מוכנה, המערכת פונה ב-API עם אותו מזהה ומושכת את כרטיס השיחה המלא לתוך המשימה.

3. לוח חי בערב התרמה. עמותה עם קו תרומות ותור של שלושים מתנדבים. Webhook על כניסה לתור ועל סיום שיחה. שרת קטן — אפילו מחשב נייד בחדר — מקבל את ההודעות ומעדכן עמוד שמוקרן על הקיר: כמה שיחות נכנסו, כמה ממתינים עכשיו, כמה נענו בעשר הדקות האחרונות. כשמספר הממתינים עולה מעל חמישה, העמוד נצבע אדום והרכז קורא לעוד מתנדבים. אין כאן כרטיסי לקוח ולא מערכת מסובכת — רק ספירה. ובכל זאת זה הכלי שמאפשר לרכז לנהל את הערב במקום לנחש.

מתי Webhook ומתי לשאול — לפי תרחיש

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

מה לסכם עם המתכנת לפני שמתחילים

דף אחד, שש שורות, וחוסכים שבוע של "למה זה לא עובד":

1. הכתובת — כתובת סופית ומאובטחת (HTTPS), בלי הפניות.
2. מתי נקרא — באיזו נקודה במסלול: כניסה לקו, כניסה לתור, סיום שיחה.
3. מה מגיע — רשימת השדות ושמותיהם המדויקים, כולל מזהה השיחה.
4. מה עונים — "קיבלתי" בלבד, או תשובה שמשפיעה על המסלול, ובאיזה פורמט.
5. כמה זמן — השרת עונה תוך שנייה; העיבוד הכבד קורה אחרי התשובה.
6. מספר לבדיקות — מספר צדדי שעליו מנסים לפני שנוגעים בקו הראשי.

ועוד שורה שכדאי להוסיף: מה קורה כשהשרת לא עונה — המשך המסלול בלי החלון, ולא שיחה שנתקעת.

טעויות נפוצות בחיבור Webhook

• לעבוד קודם ולענות אחר כך. השרת מחפש את הלקוח בשלושה מאגרים ורק אז עונה. בינתיים המתקשר מחכה. עונים "קיבלתי" מיד, ומחפשים אחרי.
• לזהות שיחה לפי מספר המתקשר. אותו לקוח מתקשר פעמיים באותו יום, והמערכת רושמת אחת. המזהה הייחודי של השיחה הוא המפתח, לא המספר.
• לבדוק על הקו הראשי. טעות בפורמט, וכל השיחות של הבוקר עוברות בלי החלון. מנסים על מספר צדדי.
• לשנות כתובת בשרת ולשכוח את לוח הבקרה. המתכנת העביר את השרת, והמרכזייה עדיין קוראת לכתובת הישנה. כל שינוי כתובת — עדכון במסך ה-Webhooks.
• להסתמך על ה-Webhook כעל יומן. השרת היה למטה שעה, ושעה של אירועים חסרה. משלימים מיומן השיחות.