בעוד שערוץ ה-webhook הנכנס מקבל אירועים חיצוניים כדי לעבד אותם, הצומת webhook_action עושה את ההיפך: הוא שולח בקשת HTTP למערכות שלכם מכל נקודה ב-pipeline — המקבילה למודולי « HTTP » של Make או « Webhooks » של Zapier.
מדוע
כנראה שכבר יש לכם:
- מערכת alerting (PagerDuty, Opsgenie, Slack).
- כלי ITSM (Jira, ServiceNow) לניהול כרטיסים.
- dashboard מותאם המרכז את המצב התפעולי שלכם.
במקום לבקש ממערכות אלה לבצע polling ל-betool, תנו ל-pipelines שלכם להודיע להן: הציבו צומת webhook_action בנקודה בגרף שבה האירוע מתרחש (אימייל שסווג, מסנן שעבר, דוח מתוזמן…). בשילוב עם ערוץ התזמון, זהו גם הבסיס לדחיפה חוזרת למערכות שלכם.
תצורת הצומת
| שדה | תפקיד |
|---|---|
url | URL יעד (ניתן לתבנית) |
method | GET / POST (ברירת מחדל) / PUT / PATCH / DELETE |
headers / query | מילונים {שם: תבנית} |
body_mode | none / json (ברירת מחדל) / form / raw / mapper / multipart |
body_template | תבנית ה-body (מצבים json / form / raw) |
mapping_spec | בניית ה-body דרך ה-payload mapper (מומלץ) — עומק, מערכים, טרנספורמציות |
auth_mode | none (ברירת מחדל) / bearer / basic / api_key_header / oauth2 (client credentials) |
auth_config | פרמטרי מצב האימות: {token}, {user, password}, {header, value} או {credential_id} |
timeout_ms | ברירת מחדל 30,000 ms |
retry_count | מספר ניסיונות חוזרים (ברירת מחדל 0, מקסימום 10), backoff אקספוננציאלי |
accepted_statuses | קודי HTTP הנחשבים הצלחה (ברירת מחדל: 200, 201, 202, 204) |
output_key | מפתח הזרימה שבו נכתבת התגובה (ברירת מחדל webhook.response) |
Templating
URL, headers, query ו-body משלבים את מפתחות הזרימה בתחביר {נתיב}:
{
"event": "order_qualified",
"order_id": "{webhook.payload.order_id}",
"verdict": "{exchange.result}"
}
אימות
- ה-credentials של המצבים
bearer/basic/api_key_header(הטוקן, הסיסמה, ערך ה-header) מאוחסנים בתצורת הצומת, אך לעולם אינם יוצאים בטקסט ברור: העורך, API הניהול, כלי ה-MCP וההצעות מציגים רק סמן «סוד שמור». בעורך, השדה מציג «•••••• שמור — הקלידו כדי להחליף»: השאירו אותו ריק כדי לשמור את הסוד, הקלידו ערך כדי להחליפו, או לחצו על הסרה כדי למחוק אותו. המזהה (user) ושם ה-header (header) נשארים קריאים. - העתקה-הדבקה או שכפול של צומת אינם מעתיקים את הסודות שלו: הזינו אותם מחדש בעותק.
- במצב
oauth2(client credentials), הצומת נושא רק הפניה ל-credential; הסוד שוכן באחסון ה-OAuth של הארגון, לעולם אינו מוחזר בקריאה, והטוקן מתקבל (ואז מתרענן) בזמן הביצוע. אותו credential משמש כמה צמתים, והחלפת הסוד אינה מצריכה עריכה מחדש של אף pipeline.
שליחת קבצים (multipart)
המצב multipart (RFC 7578) שולח שדות טקסט וקבצים מצורפים באותה בקשה — עבור שותפים שמקבלים רק multipart/form-data. הקבצים מוזכרים לפי מפתח ה-object store שלהם ונקראים מחדש ברגע השליחה (20 קבצים ו-25 MB לכל היותר); מפתח מחוץ לפרימטר של הארגון שלכם נדחה, ושליחה שחסר בה קובץ מצורף ננטשת במקום להישלח קטועה.
ניסיונות חוזרים ושגיאות
- סטטוס מחוץ ל-
accepted_statuses, timeout או שגיאת רשת מפעילים ניסיון חוזר עם backoff אקספוננציאלי (0.5 שנ׳, 1 שנ׳, 2 שנ׳, 4 שנ׳…), עדretry_countניסיונות חוזרים. - התגובה (
status,headers,body) נכתבת תחתoutput_key, עם מפתחerrorלאחר מיצוי הניסיונות החוזרים: צמתים במורד הזרם יכולים לקרוא את התוצאה ולהפעיל טיפול חלופי במקרה של כישלון. התוצאה גלויה בהיסטוריה. - אין שליחה כפולה: אם הביצוע מורץ מחדש (המשך לאחר פריסה מחדש, ניסיון חוזר של התור), קריאה שכבר התקבלה על ידי המערכת שלכם אינה נשלחת שוב.
הוכחת המקור בצד המקבל
הבקשות של webhook_action נושאות את האימות שאתם מגדירים (auth_mode): הוא שמוכיח את המקור מול המערכת שלכם. לכיוון ההפוך — אימות החתימה של מה ש-betool מקבלת — ראו Webhook נכנס.