Webhooks לאירועי מסחר וסנכרון נתונים בזמן אמת
מגדירים כתובות URL ייעודיות ו-StoreChart שולח HTTP callback חתום ומאובטח בכל פעם שמתרחש אירוע הזמנה, מלאי או שינוי לקוח.
כל אירוע ב-StoreChart, מדווח מיידית לכל מערכת
מגדירים כתובת URL אחת ומקבלים HTTP callback חתום על כל אירוע רלוונטי, בלי לבצע polling.
- כל אירוע — הזמנה, מלאי או לקוח — נשלח כ-payload JSON מלא לכתובת שהגדרתם.
- כל בקשה נחתמת בחתימת HMAC כדי לאמת שהמקור הוא StoreChart.
- כשל בקבלה מפעיל retry אוטומטי, עד 5 ניסיונות, כדי למנוע אובדן אירוע.
- אפשר להירשם רק לאירועים הרלוונטיים ולא לכל אירוע במערכת.
איך מגדירים webhook תוך כמה דקות
שלושה שלבים בין הגדרת כתובת ה-URL לקבלת ההתראה הראשונה בזמן אמת.
מוסיפים כתובת URL בהגדרות StoreChart — כתובת שמארחת שרת שמסוגל לקבל בקשות POST ולהחזיר תגובת הצלחה.
בוחרים אילו אירועים ישלחו לאותה כתובת — הזמנה חדשה, שינוי סטטוס, מלאי או לקוח — כדי לא לקבל תעבורה שאינה רלוונטית.
מרגע השמירה, כל אירוע תואם נשלח מיידית לכתובת, וניתן לראות ביומן את הסטטוס וזמן התגובה של כל בקשה.
כל ניסיון מסירה, מוצלח או כושל, מופיע בלוג הרצה עם קוד התגובה והתזמון, כך ששרת קולט שמתחיל לדחות בקשות נראה מיידית במקום להתגלות ימים אחר כך.
יכולות שנפתחות עם Webhooks
אירועים
הזמנות, שינויי מלאי, לקוחות חדשים ושינויי סטטוס — כל אחד ניתן לרישום בנפרד לכתובת שונה.
Payload מלא
כל בקשה מכילה את מלוא נתוני האירוע בפורמט JSON, בלי צורך בקריאת API נוספת לאחר מכן.
חתימת אבטחה
כל בקשה נחתמת ב-HMAC כך שאפשר לאמת בקוד המקבל שהמקור אמיתי ולא זויף.
Retry אוטומטי
בקשה שנכשלת מנוסה מחדש אוטומטית עד 5 פעמים לפני שהאירוע מסומן כלא נמסר.
סינון אירועים לפי כתובת
כל כתובת URL מוגדרת נרשמת רק לאירועים הספציפיים שהיא צריכה, כך שמערכת מחסן שעוקבת אחרי מלאי לא מקבלת אירועי לקוחות שמיועדים לנקודת קצה אחרת.
Payload מסודר וחתום בזמן
כל payload כולל חותמת זמן של האירוע, מה שמאפשר למערכת הקולטת לזהות ולהתעלם בבטחה ממסירה לא מסודרת או כפולה במקום להחיל מידע ישן על מידע חדש יותר.
מסך הגדרת Webhooks ב-StoreChart
המסך מציג את רשימת הכתובות המוגדרות, האירועים הרשומים לכל אחת, ויומן ריצה עם קוד התגובה של כל שיחת POST.
איך מפתח צריך לעצב נקודת קצה קולטת אמינה עבור webhooks של StoreChart?
Webhooks מעבירים את האחריות להישאר מעודכן מבדיקת API לפי לוח זמנים לתגובה מיידית לאירועים — אבל זה עובד טוב רק אם נקודת הקצה הקולטת בנויה נכון. נקודת הקצה צריכה להגיב מהר (תגובה איטית עלולה להתפרש ככישלון) ולהחזיר קוד סטטוס הצלחה לפני עיבוד כבד; דפוס נפוץ הוא לקבל את ה-payload, לאחסן אותו בתור או במסד נתונים מיידית, להחזיר הצלחה, ולעבד אותו באופן אסינכרוני לאחר מכן.
אימות חתימה הוא השלב הקריטי לאבטחה: כל בקשה כוללת חתימת HMAC המחושבת עם מפתח סודי ייחודי לחשבון, והקוד הקולט חייב לחשב את אותה חתימה על גוף הבקשה הגולמי ולהשוות אותה לערך הכותרת לפני שהוא סומך על ה-payload — דילוג על שלב זה משמעו שכל מי שמגלה את כתובת נקודת הקצה יכול לשלוח אירועים מזויפים. מכיוון שאין הבטחה שהמסירה תגיע בדיוק בסדר שבו האירועים קרו (במיוחד לאורך ניסיונות חוזרים), כל payload נושא חותמת זמן כך שהמערכת הקולטת יכולה לזהות ולהשליך מסירה לא מסודרת או כפולה במקום לדרוס מידע חדש יותר במידע ישן.
לגבי אמינות, מסירה כושלת — timeout, תגובת 500, או שגיאת חיבור — מפעילה עד 5 ניסיונות חוזרים אוטומטיים עם פער גדל ביניהם לפני שהאירוע מסומן כלא נמסר ונרשם לבדיקה ידנית. זה הופך את ה-webhooks לבסיס סביר לחיבור StoreChart לדשבורד BI מותאם אישית, מערכת הנהלת חשבונות חיצונית, או כלי ניהול מחסן, כל עוד הצד הקולט בנוי לצפות לניסיונות חוזרים מדי פעם ולמסירה לא מסודרת ולא לזרם רציף ומדויק לחלוטין. מכיוון שכל כתובת נרשמת באופן עצמאי, נפוץ שחשבון StoreChart בודד מריץ כמה נקודות קצה בו-זמנית — אחת מזינה דשבורד BI על הזמנות חדשות, אחרת מזינה מערכת הנהלת חשבונות על שינויי לקוחות — בלי שאחת תשפיע על התנהגות המסירה או הניסיון החוזר של האחרת.
אינטגרציות שמשלימות webhooks
שאלות נפוצות
כל webhook נשלח כבקשת HTTP POST עם גוף JSON שמכיל את סוג האירוע, חותמת זמן ואת הנתונים המלאים של הרשומה שהשתנתה.
הגדירו webhook ראשון עכשיו
מוסיפים כתובת URL, בוחרים אירועים, ומקבלים את ההתראה הראשונה תוך דקות.