Ausgehende Webhooks
Während der Kanal eingehender Webhook externe Ereignisse zur Verarbeitung empfängt, tut der Knoten webhook_action das Gegenteil: Er sendet von jeder beliebigen Stelle einer Pipeline eine HTTP-Anfrage an Ihre Systeme — das Gegenstück zu den „HTTP“-Modulen von Make oder den „Webhooks“ von Zapier.
Warum
Sie haben wahrscheinlich bereits:
- Ein Alerting-System (PagerDuty, Opsgenie, Slack).
- Ein ITSM-Tool (Jira, ServiceNow) zur Verwaltung von Tickets.
- Ein individuelles Dashboard, das Ihren operativen Status aggregiert.
Statt diese Systeme betool abfragen zu lassen, lassen Sie sie von Ihren Pipelines benachrichtigen: Platzieren Sie einen webhook_action-Knoten an der Stelle des Graphen, an der das Ereignis eintritt (eine qualifizierte E-Mail, ein passierter Filter, ein geplanter Bericht …). In Kombination mit dem Kanal Planung ist er auch die Grundlage für einen wiederkehrenden Push an Ihre Systeme.
Konfiguration des Knotens
| Feld | Funktion |
|---|---|
url | Ziel-URL (unterstützt Templates) |
method | GET / POST (Standard) / PUT / PATCH / DELETE |
headers / query | Dictionaries {Name: Template} |
body_mode | none / json (Standard) / form / raw / mapper / multipart |
body_template | Template des Bodys (Modi json / form / raw) |
mapping_spec | Aufbau des Bodys über den Payload-Mapper (empfohlen) — Verschachtelung, Arrays, Transformationen |
auth_mode | none (Standard) / bearer / basic / api_key_header / oauth2 (Client Credentials) |
auth_config | Parameter des Auth-Modus: {token}, {user, password}, {header, value} oder {credential_id} |
timeout_ms | Standard 30 000 ms |
retry_count | Anzahl der Wiederholungen (Standard 0, maximal 10), exponentieller Backoff |
accepted_statuses | HTTP-Codes, die als Erfolg gelten (Standard: 200, 201, 202, 204) |
output_key | Schlüssel im Fluss, in den die Antwort geschrieben wird (Standard webhook.response) |
Templating
URL, Header, Query und Body interpolieren die Schlüssel des Flusses mit der Syntax {Pfad}:
{
"event": "order_qualified",
"order_id": "{webhook.payload.order_id}",
"verdict": "{exchange.result}"
}
Authentifizierung
- Die Zugangsdaten der Modi
bearer/basic/api_key_headerwerden in der Konfiguration des Knotens gespeichert: Sie bleiben für Mitglieder sichtbar, die diese Pipeline öffnen können. - Im Modus
oauth2(Client Credentials) trägt der Knoten nur eine Referenz auf die Zugangsdaten; das Secret liegt im OAuth-Speicher der Organisation, wird beim Lesen nie zurückgegeben, und das Token wird zur Laufzeit bezogen (und erneuert). Dies ist der bevorzugte Modus für ein sensibles Secret.
Dateiversand (multipart)
Der Modus multipart (RFC 7578) sendet Textfelder und Anhänge in derselben Anfrage — für Partner, die nur multipart/form-data akzeptieren. Dateien werden über ihren Object-Store-Schlüssel referenziert und beim Versand neu gelesen (höchstens 20 Dateien und 25 MB); ein Schlüssel außerhalb des Bereichs Ihrer Organisation wird abgelehnt, und ein Versand, bei dem ein Anhang fehlt, wird abgebrochen, statt unvollständig gesendet zu werden.
Retries & Fehler
- Ein Status außerhalb von
accepted_statuses, ein Timeout oder ein Netzwerkfehler löst eine Wiederholung mit exponentiellem Backoff aus (0,5 s, 1 s, 2 s, 4 s …), bis zuretry_countWiederholungen. - Die Antwort (
status,headers,body) wird unteroutput_keygeschrieben, nach Ausschöpfen der Wiederholungen mit einem Schlüsselerror: Nachgelagerte Knoten können das Ergebnis lesen und im Fehlerfall eine Ausweichbehandlung auslösen. Das Ergebnis ist im Verlauf sichtbar. - Kein doppelter Versand: Wird die Ausführung erneut abgespielt (Wiederaufnahme nach einem Redeployment, Wiederholung der Warteschlange), wird ein von Ihrem System bereits akzeptierter Aufruf nicht erneut gesendet.
Herkunft auf Empfängerseite nachweisen
Die Anfragen von webhook_action tragen die Authentifizierung, die Sie konfigurieren (auth_mode): Sie weist Ihrem System gegenüber die Herkunft nach. Für die umgekehrte Richtung — die Signatur dessen prüfen, was betool empfängt — siehe Eingehender Webhook.