מה זה Webhook - ההסבר הפשוט
Webhook הוא ההבדל בין מערכת שמודיעה לכם שקרה משהו לבין מערכת שצריך לשאול אותה כל דקה. זה נשמע כמו פרט טכני זניח, ובפועל הוא קובע אם תהליך מגיב בשנייה או ברבע שעה - וכמה הוא עולה.
שתי דרכים לדעת שקרה משהו
נניח שאתם רוצים שכל תשלום שמתקבל בסליקה ייצור חשבונית אוטומטית. כדי שזה יקרה, משהו צריך לדעת שהתשלום התקבל. יש בדיוק שתי דרכים לדעת את זה, וההבדל ביניהן הוא כל התוכן של המאמר הזה.
הדרך הראשונה: לשאול. כל חמש דקות התהליך פונה למערכת הסליקה ושואל אם נכנסו תשלומים חדשים. ברוב הפעמים התשובה תהיה לא. השיטה הזאת נקראת בדיקה מחזורית, או polling. הדרך השנייה: להמתין להודעה. המערכת יודעת שאתם מתעניינים, וברגע שמתקבל תשלום היא פונה אליכם ומודיעה. זה Webhook.
מה זה Webhook, במדויק
Webhook הוא כתובת אינטרנט שאתם מוסרים למערכת מסוימת, ואומרים לה: כשיקרה האירוע הזה, שלח לכתובת הזאת הודעה עם הפרטים. מרגע ההגדרה, המערכת השולחת עושה את העבודה. אתם לא שואלים כלום - אתם מקבלים.
ההודעה עצמה היא חבילת מידע קטנה בפורמט מובנה, שמכילה בדרך כלל את סוג האירוע, את מזהה הרשומה, ולעיתים גם את הפרטים המלאים. בהרבה מערכות ההודעה מכילה רק מזהה, ואז התהליך שמקבל אותה פונה חזרה ל-API כדי למשוך את שאר הנתונים. זה שילוב נפוץ ולגיטימי לחלוטין.
השם עצמו לא מסביר כלום ולא צריך להטריד אתכם. מה שחשוב הוא הכיוון: במקום שאתם תשאלו, המערכת מספרת.
מה צריך בצד שלכם
השאלה הראשונה שעולה היא האם צריך שרת. ברוב המקרים לא. כל פלטפורמת אוטומציה מייצרת עבורכם כתובת ייעודית בלחיצה, ואתם רק מדביקים אותה בהגדרות של המערכת השולחת. מרגע זה, כל הודעה שתגיע לכתובת מפעילה את התהליך. זו אחת הסיבות שהמנגנון הזה הפך לנפוץ כל כך גם אצל עסקים בלי צוות טכני.
מה שכן חשוב הוא שהכתובת תישאר יציבה. שינוי שלה בלי לעדכן את המערכת השולחת מנתק את החיבור בשקט, וזה קורה יותר ממה שנדמה - למשל כשמישהו משכפל תהליך לצורך בדיקה ואז מוחק את המקורי. הכתובת הישנה ממשיכה לקבל הודעות שאף אחד כבר לא קורא.
אילו אירועים תמצאו במערכות שאתם מכירים
- מערכות חשבוניות: הודעה על מסמך שהופק או על תשלום שנקלט מול חשבונית פתוחה.
- ספקי סליקה: אישור עסקה שנשלח לשרת שלכם בנפרד מהחזרת הלקוח לדפדפן. זה הערוץ הקובע, ולא מה שהלקוח ראה במסך.
- מערכות CRM: אוטומציה פנימית שפונה לכתובת שלכם ברגע שסטטוס משתנה, במקום שתשאלו כל כמה דקות.
- טפסים ודפי נחיתה: כמעט כולם יודעים לשלוח את תוכן הטופס לכתובת שתגדירו, וזו הדרך הפשוטה ביותר להתחיל.
מתי כל שיטה מתאימה
| Webhook | בדיקה מחזורית | |
|---|---|---|
| זמן תגובה | שניות | כתדירות הבדיקה - לרוב 5 עד 15 דקות |
| עומס על המערכות | נמוך, פועל רק כשקורה משהו | קבוע, גם כשאין שום שינוי |
| עלות בפלטפורמות אוטומציה | לפי כמות אירועים בפועל | לפי כמות בדיקות, גם ריקות |
| מה קורה אם נופל החיבור | האירוע עלול ללכת לאיבוד | הבדיקה הבאה תתפוס את מה שהוחמץ |
| מורכבות הקמה | דורש כתובת ציבורית וטיפול בכפילויות | פשוט יותר, כמעט תמיד אפשרי |
שימו לב לשורה הרביעית, כי היא הפחות אינטואיטיבית. בדיקה מחזורית איטית יותר, אבל היא מתקנת את עצמה. אם השרת שלכם לא היה זמין לחצי שעה, הבדיקה הבאה פשוט תמשוך את כל מה שהצטבר. ב-Webhook, לעומת זאת, הודעה שנשלחה לכתובת שלא ענתה עלולה להיעלם לתמיד - תלוי כמה ניסיונות חוזרים המערכת השולחת מבצעת.
שלוש בעיות שכל מי שעובד עם Webhook פוגש
כפילויות
מערכת ששולחת Webhook מצפה לקבל אישור מהיר. אם האישור לא הגיע - כי השרת היה עסוק, כי הרשת נתקעה לשנייה - היא תשלח שוב. התוצאה היא שאותו אירוע מגיע פעמיים או שלוש. אם לא נערכתם לזה, הלקוח מקבל שתי חשבוניות על אותה עסקה.
הפתרון פשוט מבחינה רעיונית: כל אירוע נושא מזהה ייחודי, והתהליך שומר רשימה של מזהים שכבר טופלו. אירוע שכבר מוכר נזרק בשקט. בעגה המקצועית זה נקרא idempotency, ובפועל זו שורת קוד אחת שמונעת את התקלה הכי נפוצה בתחום.
סדר לא מובטח
אין שום הבטחה שהודעות יגיעו בסדר שבו האירועים קרו. עדכון סטטוס להזמנה יכול להגיע לפני ההודעה על יצירת ההזמנה עצמה. תהליך שמניח סדר כרונולוגי ייכשל באופן אקראי, וזה סוג התקלה הכי קשה לאבחון כי היא לא חוזרת על עצמה בבדיקות.
כשלים שקטים
זו הבעיה החמורה מכולן. אם הכתובת שלכם מפסיקה לענות, ברוב המערכות אף אחד לא יודיע לכם. ההודעות פשוט מפסיקות להגיע, התהליך מפסיק לרוץ, וגם אין שגיאה כי אין ניסיון. עסקים מגלים את זה כשלקוח מתקשר לשאול איפה החשבונית, לפעמים אחרי שבועיים.
תהליך שרץ על Webhook בלי ניטור נראה בדיוק אותו דבר כשהוא עובד וכשהוא מת. זו הסיבה שאנחנו לא מספקים אוטומציה בלי התראה על שקט חריג.
מה אנחנו עושים בפרויקטים בפועל
ההעדפה שלנו במרבית המקרים היא שילוב של השתיים, ולא בחירה. Webhook נותן את התגובה המהירה, ובדיקה מחזורית רחבה יותר רצה ברקע - למשל פעם בשעה - ומוודאת שלא נשמט כלום. אם היא מוצאת רשומה שלא טופלה, היא משלימה אותה בשקט. זה עולה מעט יותר ומייצר מערכת שסולחת על תקלות רשת.
- מזהה ייחודי לכל אירוע ורשימת אירועים שטופלו, כדי למנוע כפילויות.
- אימות חתימה על כל הודעה נכנסת, או לכל הפחות כתובת סודית שאי אפשר לנחש.
- מענה מהיר למערכת השולחת, ועיבוד כבד בהמשך ולא תוך כדי - הודעה שממתינה לתהליך ארוך נחשבת ככישלון ונשלחת שוב.
- יומן של כל הודעה שהתקבלה, גם כשהכל תקין. בלעדיו אי אפשר לברר מה קרה לפני שלושה ימים.
- התראה כשלא התקבלה אף הודעה בפרק זמן שאמור להיות פעיל.
מה זה אומר לכם כשאתם בוחרים מערכת
כשאתם בודקים מערכת חדשה, שאלו לא רק אם יש Webhook אלא על אילו אירועים. הרבה מערכות תומכות רק באירועים בסיסיים - יצירת רשומה, למשל - ולא בעדכונים או במחיקות. אם התהליך שלכם מסתמך על שינוי סטטוס, וזה בדיוק האירוע שלא נתמך, חזרתם לבדיקה מחזורית.
שאלה שנייה ששווה לשאול: כמה ניסיונות חוזרים המערכת מבצעת אם הכתובת לא ענתה, ולכמה זמן. מערכת שמנסה שוב במשך יום שלם סלחנית הרבה יותר ממערכת שמוותרת אחרי ניסיון אחד.
שאלה שלישית, שרלוונטית בעיקר לעסקים עם נפח גבוה: האם אפשר לבחור על אילו אירועים לקבל הודעה, או שהמערכת שולחת על כל שינוי. מערכת שמודיעה על כל נגיעה קטנה ברשומה תייצר אלפי הודעות מיותרות ביום, ובפלטפורמה שמתמחרת לפי פעולות זה מתורגם ישירות לכסף. סינון בצד השולח תמיד עדיף על סינון אצלכם.
מה עושים כשהוובהוק נכשל
זה החלק שמפריד בין חיבור שעובד בהדגמה לחיבור שעובד בעסק. וובהוק הוא הודעה שנשלחת פעם אחת, ואם הצד שמקבל אותה לא היה זמין באותו רגע, ההודעה עלולה פשוט להיעלם. בלי טיפול מסודר זה נראה כמו הזמנה שנכנסה למערכת אחת ולא לשנייה, ואף אחד לא יודע למה.
| תרחיש כשל | מה קורה בלי טיפול | מה בונים במקום |
|---|---|---|
| השרת שלכם היה למטה | ההודעה אבדה | תור הודעות שמאחסן עד שהמערכת חוזרת |
| ההודעה הגיעה פעמיים | רשומה כפולה או חיוב כפול | מזהה ייחודי לכל אירוע ובדיקה אם כבר טופל |
| הודעות הגיעו לא בסדר | מצב שגוי, למשל ביטול לפני יצירה | חותמת זמן ובדיקת סדר לפני עדכון |
| הצד השולח שינה מבנה | התהליך נשבר בשקט | בדיקת מבנה והתראה על שדה חסר |
השורה השנייה בטבלה היא הכי חשובה למי שעובד עם כסף. ספקים רבים שולחים את אותה הודעה יותר מפעם אחת בכוונה, כדי להבטיח שהיא הגיעה. אם המערכת שלכם לא בודקת שהיא כבר טיפלה באירוע הזה, לקוח יקבל שתי חשבוניות.
אבטחה: איך יודעים שההודעה באמת הגיעה מהם
כתובת וובהוק היא כתובת פתוחה באינטרנט. כל מי שמכיר אותה יכול לשלוח אליה מה שהוא רוצה, כולל הודעה שנראית כמו תשלום שהתקבל. זו לא תיאוריה, זו נקודת תורפה אמיתית בעסקים שמחברים סליקה למערכת פנימית.
- חתימה: ספקים רציניים חותמים כל הודעה במפתח סודי. המערכת שלכם מוודאת את החתימה לפני שהיא עושה משהו עם התוכן.
- כתובת שקשה לנחש: לא לחשוף את הכתובת בתיעוד פומבי או בצד לקוח.
- אימות מול המקור: בפעולות רגישות, במקום להאמין לתוכן ההודעה, פונים חזרה לספק ושואלים מה הסטטוס האמיתי.
- הגבלת קצב: מספר מקסימלי של הודעות לדקה, כדי שהצפה לא תפיל את המערכת.
הכלל הפשוט: וובהוק אומר לכם שקרה משהו. הוא לא מקור אמת לגבי מה בדיוק קרה. בפעולות שכרוכות בכסף, תמיד לוודא מול המקור.
השורה התחתונה
Webhook הוא מנגנון פשוט שפותר בעיה אמיתית: הוא מוריד השהיה ועומס, והופך תהליכים לתגובתיים במקום עצלים. הוא גם מנגנון שדורש משמעת - כפילויות, סדר וניטור הם לא מקרי קצה נדירים אלא ההתנהגות היומיומית שלו.
אם מישהו מציע לכם אוטומציה שמבוססת על Webhook ולא מזכיר אף אחד משלושת הדברים האלה, שווה לשאול איך הוא מתכוון לטפל בהם. התשובה תלמד אתכם הרבה.
שאלות שחוזרות
- מה ההבדל בין Webhook ל-API?
- זה אותו עולם, בכיוון הפוך. ב-API אתם פונים למערכת ומבקשים מידע. ב-Webhook המערכת פונה אליכם מיוזמתה כשקורה משהו. רוב האינטגרציות משתמשות בשניהם: Webhook כדי לדעת שקרה אירוע, ואז קריאת API כדי למשוך את כל הפרטים.
- האם Webhook עולה כסף?
- המנגנון עצמו לרוב לא. מה שכן עולה זה הכלי שמקבל את ההודעה. פלטפורמות כמו Make מתמחרות לפי מספר פעולות, ולכן מערכת שמפציצה בעדכונים על כל שינוי קטן יכולה לייצר חשבון מפתיע. זה שיקול אמיתי בבחירת ארכיטקטורה, ולא פרט שולי.
- המערכת שלנו לא תומכת ב-Webhook. מה עושים?
- עוברים לבדיקה מחזורית - האוטומציה שואלת את המערכת בתדירות קבועה אם השתנה משהו. זה עובד טוב, בתנאי שהמערכת מאפשרת לסנן לפי תאריך עדכון. ההשלכה היחידה היא השהיה: תהליך יגיב תוך דקות ולא תוך שניות, ולרוב התהליכים העסקיים זה לגמרי מספיק.
- למה קיבלנו את אותה הודעה פעמיים?
- זו התנהגות תקינה ולא תקלה. אם המערכת השולחת לא קיבלה אישור בזמן, היא שולחת שוב. לכן כל תהליך שמקבל Webhook חייב לזהות אירוע שכבר טופל ולהתעלם ממנו. בלי זה מקבלים שתי חשבוניות לאותה הזמנה, וזו טעות שלוקח זמן לגלות.
- האם Webhook מאובטח?
- הכתובת שמקבלת את ההודעות פתוחה לאינטרנט, ולכן היא צריכה הגנה. המנגנון המקובל הוא חתימה סודית שהמערכת השולחת מצרפת לכל הודעה, והמקבל מאמת אותה. אם המערכת לא תומכת בחתימה, אפשר להשתמש בכתובת ארוכה ובלתי ניתנת לניחוש ולסנן לפי כתובות IP מאושרות.
- מה ההבדל בין וובהוק לבדיקה תקופתית?
- וובהוק דוחף אליכם עדכון ברגע שקורה משהו, ולכן הוא מיידי וחסכוני. בדיקה תקופתית שואלת שוב ושוב אם יש חדש, ולכן היא איטית יותר ויקרה יותר, אבל אמינה יותר כי היא לא תלויה בהודעה בודדת שיכולה ללכת לאיבוד. במערכות שחשוב שלא יפספסו כלום אנחנו לרוב משלבים: וובהוק למהירות, ובדיקה תקופתית כרשת ביטחון.