Webhooks haben meine Sichtweise auf die Automatisierung von KI-Agenten verändert. Vor Webhooks basierten meine Automatisierungen alle auf Zeit: Überprüfung neuer E-Mails alle 5 Minuten, Scannen von GitHub-Benachrichtigungen alle 10 Minuten, Abfragen des Serverstatus jede Stunde. Mit Webhooks kommen die Ereignisse zu mir. Keine Abfragen. Keine Wartezeiten. Keine verschwendeten API-Aufrufe, um zu überprüfen, ob sich etwas geändert hat.
Der Unterschied ist wie das Überprüfen Ihres Briefkastens alle 5 Minuten im Vergleich dazu, eine Klingel zu haben, die läutet, wenn die Post ankommt. Das eine ist ineffektiv und lästig. Das andere funktioniert einfach.
Was Webhooks für einen KI-Agenten tun
Ein Webhook ist eine URL, die HTTP POST-Anfragen erhält, wenn etwas passiert. GitHub kann einen Webhook senden, wenn ein PR geöffnet wird. Stripe kann einen Webhook senden, wenn eine Zahlung fehlschlägt. Ihr Überwachungssystem kann einen Webhook senden, wenn ein Server ausfällt.
OpenClaw kann diese Webhooks empfangen und darauf reagieren. Die Antwort ist nicht einfach „speichern“ – es ist „verstehen, was passiert ist, und intelligent handeln.“
Webhook PR GitHub → OpenClaw liest den PR, prüft den Code, veröffentlicht eine Zusammenfassung und erste Kommentare. Dies geschieht innerhalb von 30 Sekunden nach Öffnung des PR. Bei Abfragen hätte es eine Verzögerung von 5 bis 10 Minuten gegeben.
Webhook bei fehlgeschlagenem Zahlung → OpenClaw überprüft die Historie des Kunden, verfasst eine geeignete E-Mail (bestehender Kunde vs. neuer Kunde, erster Fehler vs. wiederkehrendes Problem) und setzt sie zur Überprüfung in die Warteschlange. Reaktionszeit: weniger als eine Minute.
Webhook Serveralarm → OpenClaw prüft die aktuellen Protokolle des betroffenen Servers, identifiziert wahrscheinliche Ursachen und veröffentlicht eine vorläufige Diagnose im Slack-Kanal des Teams. Das Team erhält Kontext mit der Warnung, nicht nur „Der Server X ist ausgefallen.“
Einrichtung von Webhooks
OpenClaw kann Webhooks über seinen API-Endpunkt empfangen. Die Einrichtung:
1. Konfigurieren Sie OpenClaw so, dass es Webhooks an einem bestimmten Endpunkt empfängt
2. Konfigurieren Sie den externen Dienst so, dass er Webhooks an diesen Endpunkt sendet
3. Schreiben Sie Verarbeitungsanweisungen in die Konfiguration Ihres Agenten: „Wenn Sie einen Webhook von GitHub mit der Aktion ‘opened’ und dem Typ ‘pull_request’ erhalten, überprüfen Sie den PR und veröffentlichen Sie einen Kommentar“
Der externe Dienst muss in der Lage sein, Ihre OpenClaw-Instanz zu erreichen, was bedeutet, entweder: Ihr Server hat eine öffentliche URL (am einfachsten), oder Sie verwenden einen Tunnel-Service wie ngrok oder Tailscale (für Heimkonfigurationen), oder Sie verwenden einen Webhook-Relay-Service, der die Webhooks zwischenspeichert und ausliefert, wenn Ihr Agent eine Verbindung herstellt.
Die Workflows, die ich erstellt habe
Deployment-Benachrichtigungspipeline. Wenn der Code in den Hauptbranch zusammengeführt wird (Webhook von GitHub), macht OpenClaw:
1. Überprüft, ob CI erfolgreich war
2. Löst das Deployment aus, wenn der CI grün ist
3. Überwacht das Deployment für 5 Minuten
4. Veröffentlicht ein Statusupdate auf Slack mit den bereitgestellten Änderungen
5. Wenn etwas schiefgeht, rollt zurück und warnt das Team
Dies hat einen manuellen Deployment-Prozess ersetzt, der 15 Minuten menschliche Aufmerksamkeit pro Deployment benötigte. Jetzt erfordert es null menschliche Aufmerksamkeit für erfolgreiche Deployments und etwa 2 Minuten für Fehlschläge (Überprüfung der Warnung und Entscheidung, ob das Zurückrollen ausreichend war).
Kundensupport-Triage. Wenn ein Support-Ticket erstellt wird (Webhook des Supportdienstes), macht OpenClaw:
1. Liest den Inhalt des Tickets
2. Überprüft den Status des Kundenkontos und seine jüngste Historie
3. Kategorisiert das Problem (Abrechnung, technische Probleme, Feature-Anfrage, anderes)
4. Für häufige Probleme: Verfasst eine Antwort
5. Für komplexe Probleme: Weist es dem richtigen Teammitglied mit Kontext zu
6. Für dringende Probleme: Sendet sofort eine Benachrichtigung auf Slack
Inhaltsüberwachung. Wenn jemand unser Produkt in sozialen Medien erwähnt (Webhook eines Überwachungstools), macht OpenClaw:
1. Liest die Erwähnung und bewertet das Sentiment
2. Positive Erwähnungen: speichert zur Sammlung sozialer Beweise
3. Neutrale Erwähnungen: speichert und überspringt
4. Negative Erwähnungen: warnt das Team mit Kontext und vorgeschlagener Antwort
Häufige Fehler
Keine Signaturüberprüfung. Webhooks sind HTTP-Anfragen aus dem Internet. Jeder, der Ihre Endpunkt-URL kennt, kann gefälschte Webhooks senden. Überprüfen Sie immer die Signaturen der Webhooks – die meisten Dienste signieren ihre Webhooks mit einem geheimen Schlüssel. Weisen Sie Anfragen mit ungültigen Signaturen zurück.
Keine Idempotenz. Webhook-Dienste senden manchmal dasselbe Ereignis zweimal (Netzwerk-Wiederholungen, Dienstneustarts). Ihr Handler muss dasselbe Ergebnis erzeugen, egal ob er ein Ereignis einmal oder fünfmal erhält. Fügen Sie eine Überprüfung hinzu: „Habe ich das Ereignis mit dieser ID bereits verarbeitet? Wenn ja, überspringen.“
Langsame Verarbeitung blockiert die Antwort. Der externe Dienst erwartet eine schnelle Antwort (in der Regel innerhalb von 5 bis 30 Sekunden). Wenn Ihr Handler 2 Minuten benötigt, um das Ereignis zu verarbeiten, kann der Dienst ablaufen und es erneut versuchen, was zu einer doppelten Verarbeitung führt. Lösung: Antworten Sie sofort mit einem Status 200 und verarbeiten Sie das Ereignis dann asynchron.
Keine Fehlerbehandlung bei nachgelagerten Ausfällen. Ihr Webhook-Handler ruft eine API auf, die offline ist. Und jetzt? Das Ereignis ist verloren, es sei denn, Sie haben eine Wiederholungslogik oder eine Queue für fehlgeschlagene Ereignisse implementiert. Ich speichere alle Webhook-Payloads und markiere sie als verarbeitet/fehlgeschlagen. Fehlgeschlagene Ereignisse werden automatisch nach 5 Minuten bis zu 3 Mal wiederholt.
Wann Webhooks vs. Polling verwenden
Verwenden Sie Webhooks, wenn: Der externe Dienst sie unterstützt, Sie eine nahezu Echtzeit-Antwort benötigen und die Häufigkeit der Ereignisse unregelmäßig ist (kann 0 Ereignisse pro Stunde oder 50 sein).
Verwenden Sie Polling, wenn: Der Dienst unterstützt keine Webhooks, Sie über Zeit Daten aggregieren (Überprüfung von Metriken, keine Antwort auf Ereignisse) oder Ihre Infrastruktur keinen öffentlichen Endpunkt hat.
In der Praxis verwende ich Webhooks für alle ereignisgesteuerten Workflows und Polling nur für Datenaggregationsaufgaben. Die Kombination deckt alles ab, was ich brauche.
🕒 Published: