אירועים נכנסים, לא רק יוצאים

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

בקצרה

מקור מכניס אירועים; יעד (endpoint) מוציא אותם. שניהם חולקים צינור אחד.
מקורות דחיפה (Stripe, SendGrid, GoHighLevel, n8n, Postmark) נבדקים כבר בכניסה: חתימה על הבייטים הגולמיים, לפני שמשהו נשמר.
מקורות משיכה (OpenAI, Anthropic) נקראים לפי לוח זמנים עם סמן: שימוש בטוקנים ועלות לכל מודל הופכים לאירועים.
המחברים מנרמלים: payment.succeeded עם amount_cents, לא גוש בפורמט של הספק. אירועים שלא מופו עוברים הלאה ולא נזרקים.
מקורות קיימים שומרים על שמות האירועים הישנים שלהם. שמות קנוניים חלים רק על מקורות שנוצרים מעכשיו, כך ששום מסנן לא נשבר.

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

הקטלוג

ספק	מפתח	אופן	אימות	מה הוא מייצר
Stripe	stripe	דחיפה	חתימת HMAC	תשלום, החזר, חשבונית, מנוי, מחלוקת
GoHighLevel	gohighlevel	דחיפה	Ed25519 / RSA	ליד, עסקה, פגישה
SendGrid	sendgrid	דחיפה	ECDSA P-256	מייל נמסר, נפתח, נלחץ, חזר
Postmark	postmark	דחיפה	טוקן משותף	מייל נמסר, חזר, סומן כספאם
n8n	n8n	דחיפה	טוקן משותף	הרצת workflow הצליחה או נכשלה
Twilio	twilio	דחיפה	חתימת HMAC	שיחות נכנסות, שיחות שלא נענו, SMS
Meta Lead Ads	meta-leads	דחיפה	חתימת HMAC	לידים מטפסים בפייסבוק ובאינסטגרם
OpenAI	openai	משיכה	מפתח אדמין	טוקנים ועלות לכל מודל, כל שעה
Anthropic	anthropic	משיכה	מפתח אדמין	טוקנים ועלות של Claude לכל מודל, כל שעה
Google Analytics 4	google-analytics	משיכה	חשבון שירות	סשנים, משתמשים ואירועי מפתח יומיים, לפי ערוץ, מכשיר ומדינה; מאתר לבד כל property
Search Console	google-search-console	משיכה	חשבון שירות	קליקים, חשיפות ומיקום, יומי
Meta Ads	meta-ads	משיכה	טוקן גישה	הוצאה, חשיפות, קליקים ו-reach, יומי
TikTok Ads	tiktok-ads	משיכה	טוקן גישה	הוצאה, חשיפות, קליקים ו-reach, יומי

לצד אלה, 15 ספקים נכנסים, ביניהם GitHub, Shopify, Standard Webhooks ו-Alibaba EventBridge, נבדקים בכניסה ועוברים הלאה תחת שמות הנושא שלהם. תמיד מאמתים לפני שהאירוע נוצר.

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

מעטפה אחת, מכל ספק

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

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

"occurredAt": "2026-08-20T18:20:00.000Z" מתי זה קרה במקור. receivedAt נשמר בנפרד, כך שעיכובים אצל הספק נשארים גלויים

"entity": {"type":"customer","id":"cus_9"} במי או במה מדובר. מזהים נמצאים כאן, אף פעם לא ב-attributes

"attributes": {"provider":"stripe","currency":"usd"} רק דברים שמקבצים לפיהם. מזהים, כתובות מייל וכתובות URL נדחים לפי השם

"metrics": {"amount_cents":4299} רק מספרים סופיים, והיחידה בשם. כל סכום כסף באגורות, לא משנה מה הספק מדווח

"privacy": {"classification":"confidential","containsPii":true} מוצהר לכל אירוע. ברירת המחדל היא הרמה המחמירה ביותר, בכוונה

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

כל סכום כסף נשמר באגורות (cents). Stripe מדווחת באגורות, GoHighLevel ביחידות מטבע שלמות, Anthropic באגורות כמחרוזת עשרונית. כל מחבר ממיר בגבול שלו, כך ש-amount_cents אומר אותו דבר בכל מקום. מספר שמשלב כמה מקורות ואי אפשר לסמוך עליו גרוע מאין מספר בכלל.

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

צעד	מקור דחיפה	מקור משיכה
1	יוצרים את המקור ומקבלים כתובת קליטה וסוד	יוצרים את המקור עם פרטי הגישה של הספק
2	מדביקים את הסוד בהגדרות הוובהוקים של הספק	בוחרים מרווח (ברירת מחדל 5 דקות) וכמה אחורה למלא (עד 90 יום)
3	האירועים מגיעים, מאומתים ומנורמלים	הסנכרון הראשון רץ מיד; התקינות מדווחת לכל מקור

curl -X POST https://api.hookget.com/v1/sources \
  -H "authorization: Bearer $HOOKGET_KEY" \
  -H "content-type: application/json" \
  -d '{"provider":"stripe","name":"prod payments"}'

# {"id":"src_…","secret":"whsec_…","ingest_path":"/ingest/src_…","mode":"push"}

בלי הנחות

עובדה	למה זה כך
סנכרון משיכה מדלג על כ-90 הדקות האחרונות	הספקים ממשיכים לכתוב לחלון הנוכחי; קריאה מוקדמת שלו הייתה סופרת את אותה שעה פעמיים בסנכרון הבא.
סנכרון שנכשל שומר על הסמן הקודם	סמן שמתקדם באמצע כשל מדלג בשקט על אירועים. קריאה חוזרת לא עולה כלום, כי מזהה המסירה של הספק מונע כפילויות.
מקור שנכשל ב-20 סנכרונים ברצף משהה את עצמו	ניסיונות חוזרים עם מפתח שבוטל, כל חמש דקות בלי סוף, רק יגרמו לספק להגביל את הקצב שלנו בשמכם.
Postmark ו-n8n מאומתים בטוקן, לא בחתימה	אף אחד מהם לא מציע חתימה על תוכן האירוע. אנחנו מציינים את האימות החזק ביותר שקיים, ולא רומזים על חתימה שאין.
האימות של GoHighLevel מוכיח את השולח, לא את החשבון	GHL חותמת עם זוג מפתחות אחד לכל הלקוחות שלה. סננו לפי `locationId` אם ההבחנה חשובה לכם.

לקריאה נוספת

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

שאלות

מה זה מקור אירועים?

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

במה זה שונה מ-15 הספקים הנכנסים שכבר היו?

הספקים האלה מאמתים את החתימה של הספק ומעבירים את הגוף כמו שהוא, תחת שם הנושא של הספק עצמו: github.push, shopify.orders.create. הם ממשיכים לעבוד בלי שינוי. המחברים בעמוד הזה גם מנרמלים: payment_intent.succeeded של Stripe הופך ל-payment.succeeded, עם הסכום כמדד באגורות (cents) והלקוח כישות, כך שמסנן אחד או התראה אחת מכסים כל ספק תשלומים שחיברתם.

השמות הקנוניים ישברו את המסננים הקיימים שלי?

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

מה קורה לסוג אירוע שלא מופה?

הוא שומר על השם של הספק וממשיך לזרום. ל-Stripe לבד יש כמה מאות סוגי אירועים; הסט הממופה מכסה את מה שצינור הכנסות צריך, וכל השאר מגיע בתור stripe.<their name> ולא נזרק. התכנון לא מאפשר לאבד charge.dispute.created רק כי עוד לא מיפינו אותו.

לאן האירועים הולכים?

לכל מקום ש-HookGet מוסר אליו: יעדי HTTPS, תורים ו-bus (SQS, EventBridge, Kafka, RabbitMQ, Pub/Sub), אחסון תואם S3, או סמן משיכה (polling cursor). מסננים ועיבוד מקדים חלים לכל יעד בנפרד, כך שאותו payment.succeeded יכול להגיע למחסן הנתונים שלכם במלואו, ולהתראה ב-Slack עם שלושה שדות בלבד.

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

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

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

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