מה זה Webhook? הסבר פשוט + משרות פתוחות בישראל

Webhook הוא קריאת HTTP שמערכת חיצונית שולחת אליכם ברגע שקורה אירוע - תשלום שבוצע, סטטוס שהשתנה, הודעה שהתקבלה - במקום שאתם תשאלו שוב ושוב אם משהו קרה. זהו היפוך כיוון הזרימה. בלוח HiTakeJob פתוחות כרגע 26 משרות שמזכירות REST API ו-52 שמזכירות Node.js.

מה ההבדל מ-API רגיל

	קריאת API רגילה	Webhook
מי יוזם	אתם	המערכת החיצונית
מתי	כשאתם צריכים	ברגע שהאירוע קורה
עומס	בקשות חוזרות גם כשאין חדש	רק כשיש משהו
מה נדרש מכם	קוד שפונה החוצה	כתובת ציבורית שמקבלת
עיכוב	עד מרווח הבדיקה הבא	כמעט מיידי

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

איך זה עובד מקצה לקצה

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

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

איך מאמתים שהקריאה אמיתית?

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

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

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

למה חייבים לתמוך בקבלה כפולה

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

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

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

איך בונים נקודת קצה שמקבלת אירועים

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

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

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

מתי כדאי להשתמש בזה ומתי לא

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

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

מה עוד משתבש בפועל

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

איפה זה מופיע בעבודה בישראל

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

גם מי שאינו מפתח ווב נתקל בזה: אנשי אוטומציה ואינטגרציה בונים תהליכים שמתחילים בקבלת אירוע. אפשר לראות משרות רלוונטיות במשרות Node.js ובמשרות REST API, ואת ההקשר הרחב במה זה API.

שאלות נפוצות

מה ההבדל בין webhook ל-polling?

ב-polling אתם שואלים שוב ושוב אם קרה משהו, ומשלמים בבקשות ובעיכוב. ב-webhook הצד השני מודיע לכם ברגע האירוע. המחיר הוא שצריך נקודת קצה ציבורית, אימות, ועמידות לכפילות.

מה מחזירים בתשובה?

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

איך בודקים webhook בפיתוח?

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

מה עושים כשמפספסים אירועים?

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

האם זה בטוח לחשוף כתובת כזו לאינטרנט?

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

איך יודעים שהאירועים הפסיקו להגיע?

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

מה זה תור מתים?

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