צינור האירועים של כל הפעילות שלכם

הנתונים שלכם בזרם אחד. ה-⁠AI שלכם בפיקוד.

Q: הצרכנים שלנו יצטרכו לשנות את אימות החתימות?

HookGet חותם לפי Standard Webhooks , כך שצרכן שכבר מאמת חתימה בסגנון Svix לא צריך שום שינוי. צרכן שנכתב לשיטת חתימה פרטית צריך קטע אימות קצר, בערך חמש עשרה שורות בכל שפה.

Q: איפה הנתונים נשמרים?

באיחוד האירופי, בפרנקפורט ( eu-central-1 ). שם המערכת נבנתה, ואין אזור אחר לבחור בו או לשלם עליו. הפרטים בעמוד האבטחה .

Q: יש מסלול חינם?

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

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

להתחיל בחינם לתת הוראות לצינור

בלי כרטיס אשראי. פרויקט חי ופרויקט בדיקה מהדקה הראשונה.

ציר זמן של מסירה order.created

ניסיון 1נכשלHTTP 503 · 1,204 ms

ניסיון חוזר בעוד 30 שניות
ניסיון 2נכשלtimeout · 15,000 ms

ניסיון חוזר בעוד 2 דקות
ניסיון 3נמסרHTTP 200 · 21 ms

{"received":true}

בקצרה

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

מה מקבלים על POST אחד

הצינור שמאחורי קריאת פרסום אחת, לפי סדר הריצה.

קודם כול, שמירה

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

חתום ביציאה

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

ניסיונות חוזרים בקצב שאתם בוחרים

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

נשמר כשהוא נכשל

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

מושבת לפני שהוא מזיק

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

גלוי בזמן אמת

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

פרסום הוא בקשה אחת

כל שאר היכולות של המוצר זמינות באותו API ועם אותו מפתח API.

curl -X POST https://api.hookget.com/v1/events \
  -H "authorization: Bearer $HOOKGET_KEY" \
  -H "content-type: application/json" \
  -d '{"type":"order.created","payload":{"id":"ord_10241","total":149.9}}'

# 202 Accepted: האירוע נשמר, והפיזור ליעדים התחיל
# {"id":"msg_01M0…","type":"order.created","units":1,"endpoints":2}

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

לשנות את צורת המסירה בלי לכתוב קוד

שש פעולות הצהרתיות לכל יעד: pick, omit, rename, set, unwrap ו-wrap. העיבוד המקדים רץ לפני החתימה, כך שהחתימה מכסה בדיוק את הבתים שמגיעים. ואת ה-JavaScript שלכם אנחנו לא מריצים בתהליך המסירה אף פעם, במכוון.

מה שפורסם

{
  "type": "order.created",
  "data": {
    "order": { "id": "ord_10241" },
    "card": "4242 4242 4242"
  }
}

מה שנמסר · החתימה על הבתים האלה

{
  "type": "order.created",
  "data": {
    "order": { "id": "ord_10241" }
  },
  "via": "hookget"
}

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

טענות שאפשר לבדוק בעמודים שלהם, לא שלנו

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

$8 לכל מיליון נוסף מעבר להיקף של מסלול בתשלום, החיוב על חריגה הנמוך ביותר שמפורסם בתחום. ב-Svix המחיר הוא $100 למיליון. 50 כשלים או 410 אחד אחרי זה אנחנו משביתים יעד מת. לפי התיעוד של Svix עצמה, אצלם זה לוקח חמישה ימים של כשלים. $449 מול $490 המדרגה הראשונה בתשלום, כאן וב-Svix. שני המספרים מפורסמים, ושניהם מקושרים. 3 מתוך 5 מוצרים בתחום עם מסלול חינם מנוהל וקבוע: HookGet, Svix ו-Hookdeck. ההשוואה מפרטת מתי כל אחד מהם הוא הבחירה הנכונה.

אירועים נכנסים גם פנימה: 27 מקורות

זה הכיוון ההפוך מיעד. Stripe, SendGrid, GoHighLevel, n8n ו-Postmark דוחפים פנימה וובהוקים מאומתים. OpenAI, Anthropic, Google Analytics, Search Console, Meta Ads ו-TikTok Ads נקראים לפי לוח זמנים. Twilio מביא שיחות נכנסות, ו-Meta Lead Ads מביא לידים מפייסבוק ומאינסטגרם. עוד חמישה עשר ספקים מאומתים ומועברים הלאה כמו שהם. הכול נוחת על אותו צינור, עם אותם ניסיונות חוזרים, אותו ציר זמן ואותה שליחה חוזרת.

מאומת, לא רק מתקבל

שום דבר לא נכנס לפני שהחתימה של הספק עצמו נבדקת על הבתים המקוריים: ה-HMAC של Stripe, ה-ECDSA של SendGrid, ה-Ed25519 של GoHighLevel, GitHub, Shopify ועוד.

אחיד, כדי שכלל אחד יכסה הכול

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

ההוצאות שלכם, כאירועים

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

למקורות מעקב עלויות מודלי שפה

חוזה המסירה, בטבלה אחת

ברירות המחדל, ומה אפשר לשנות.

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

התנהגות	מה HookGet עושה
לוח ניסיונות חוזרים	8 ניסיונות לאורך כ-21 שעות, ואפשר לקבוע לוח משלכם לכל יעד
אישור קבלה	202 רק אחרי שהאירוע נכתב; התור נגזר מהאחסון
חתימה	Standard Webhooks על הבתים המקוריים, עם החלפת סודות בחפיפה כך ששום דבר לא נופל. HMAC (`v1`) או ed25519 (`v1a`), לפי בחירה לכל יעד
מניעת כפילויות	מפתח פרסום מסנן כפילויות אצל המפרסם; אצל הצרכן, מזהה המסירה קבוע בכל הניסיונות החוזרים
תור הכשלים (DLQ)	נשמר וניתן לשליחה חוזרת, עם מזהה האירוע המקורי
השבתה אוטומטית	אחרי 50 כשלים רצופים, או מיד על 410 Gone; ההשבתה מתפרסמת כאירוע
מגבלת קצב	דלי אסימונים (token bucket) לכל יעד, ועוד מגבלה לכל פרויקט ולכל מקור נכנס
סינון	לפי סוג אירוע ולפי מאפיינים בתוכן האירוע: יעד שרוצה אזור אחד מקבל אזור אחד
סדר	לכל יעד, בחלוקה לשארדים: מסירות ליעד אחד שומרות על הסדר שלהן
בטיחות תעבורה יוצאת	כתובות פרטיות וכתובות metadata נחסמות, בקוד ושוב בשכבת הרשת
מדידה	כל 64KB של תוכן אירוע הם יחידה אחת, בעיגול כלפי מעלה, והמספר חוזר בכל פרסום

מה רואים בפועל

התמיכה שואלת "שלחנו או לא?". זו התשובה, בלי שאילתה למסד הנתונים.

msg_01J8ZQ3F9VBAQ4E1S0TZY6P8YV ⁦order.created⁩ · 2 יחידות

#	שעה	סטטוס	קוד	זמן תגובה	למה
1	09:41:02	נכשל	503	1,204 ms	השירות לא זמין
2	09:41:07	נכשל	503	980 ms	ניסיון חוזר אחרי 5 שניות
3	09:41:37	נכשל	timeout	15,000 ms	ניסיון חוזר אחרי 30 שניות
4	09:46:37	נמסר	200	142 ms	ניסיון חוזר אחרי 5 דקות

אותו webhook-id בכל ניסיון, כך שהצרכן יכול לסנן כפילויות.

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

החלטות שקיבלנו במכוון

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

עיבוד מקדים הוא הצהרתי, אף פעם לא קוד של לקוח. שש פעולות שאפשר לבקר לכל יעד. תהליך מסירה שמריץ JavaScript של לקוחות חושף את כל שאר הלקוחות לנזק, ולכן אצלנו הוא לא ירוץ. לוגיקה חופשית שייכת לצד המפרסם, בקוד שלכם ובתנאים שלכם.
פיתוח מקומי הוא מאזין חתום, לא מנהרה. כלי שורת פקודה בקובץ אחד מעביר אירועים חיים ל-localhost עם חתימות אמיתיות, בלי לפתוח שום דבר לאינטרנט, ולכן סקירת אבטחה מאשרת אותו בלי ויכוח.
היעדים הם HTTPS ואחסון אובייקטים. שניהם חתומים, ושניהם בכל מסלול. מתווכי הודעות (brokers) נמצאים בתוכנית העבודה. עד שיגיעו, דלי אחסון הוא נקודת האיסוף העמידה.
תאימות היא קודם רשימה שאפשר לבדוק, ורק אחר כך תג. עמוד התאימות מציג כל בקרה שפועלת היום; ל-SOC 2 נתחייב ברגע שחוזה ידרוש אותו.
אירוח עצמי נמצא בשלבי אריזה. אותו מנוע, קובץ compose אחד. אם זה מה שעוצר אתכם, דברו איתנו ותהיו הראשונים.

לא מסכימים עם החלטה? עמודי ההשוואה מראים ביושר מי בחר בדיוק הפוך.

שאלות

מה זה שירות מסירת וובהוקים?

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

במה זה שונה מתור הודעות?

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

הצרכנים שלנו יצטרכו לשנות את אימות החתימות?

HookGet חותם לפי Standard Webhooks, כך שצרכן שכבר מאמת חתימה בסגנון Svix לא צריך שום שינוי. צרכן שנכתב לשיטת חתימה פרטית צריך קטע אימות קצר, בערך חמש עשרה שורות בכל שפה.

איפה הנתונים נשמרים?

באיחוד האירופי, בפרנקפורט (eu-central-1). שם המערכת נבנתה, ואין אזור אחר לבחור בו או לשלם עליו. הפרטים בעמוד האבטחה.

מה קורה כשיעד לא זמין במשך שעות?

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

יש מסלול חינם?

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

להתחיל למסור וובהוקים היום

מפנים את הוובהוקים ל-HookGet ורואים את המסירה הראשונה מגיעה, חתומה, תוך פחות מדקה.

פתיחת חשבון חינם לנסות את בודק הוובהוקים החינמי

10,000 מסירות בחודש בחינם, בלי כרטיס אשראי. המסלול החינמי חוסם ולא מחייב, כך שניסיון לא יכול להסתיים בחשבונית.