Ein Webhook ist ein Mechanismus, bei dem ein System bei einem bestimmten Ereignis automatisch eine HTTP-Anfrage an eine zuvor konfigurierte Empfänger-URL sendet. Dadurch kann ein Zielsystem zeitnah auf Ereignisse reagieren, ohne die Quelle fortlaufend per API abfragen zu müssen.
Wie funktioniert ein Webhook?
Bei einem Webhook registriert ein empfangendes System eine URL beim Quellsystem. Tritt ein definiertes Ereignis auf, sendet die Quelle eine HTTP-Anfrage an diese URL. Das Zielsystem kann die Nachricht validieren und anschließend einen eigenen Prozess starten.
GitHub beschreibt Webhooks beispielsweise als Mechanismus, mit dem Anwendungen Ereignisse abonnieren und bei Eintritt automatisch eine Datenlieferung an den eigenen Server erhalten.
Webhook statt Polling
Ohne Webhook würde eine Anwendung möglicherweise alle paar Minuten per API fragen: „Gibt es einen neuen Auftrag?“ oder „Ist die Zahlung inzwischen abgeschlossen?“ Dieses Polling erzeugt viele Anfragen, auch wenn sich nichts verändert hat.
Mit Webhook sendet das Quellsystem beim Ereignis selbst eine Nachricht. Das kann Reaktionszeit und unnötige Abfragen reduzieren. Trotzdem ist Polling nicht grundsätzlich falsch: Wenn ein Quellsystem keine Webhooks anbietet oder garantierte Nachsynchronisation nötig ist, können beide Muster kombiniert werden.
Typischer Ablauf
- Empfänger stellt einen HTTPS-Endpunkt bereit.
- Die URL wird beim Quellsystem für ausgewählte Events registriert.
- Ein Ereignis tritt ein.
- Das Quellsystem sendet einen Payload.
- Der Empfänger prüft Herkunft, Signatur und Inhalt.
- Die Nachricht wird möglichst schnell bestätigt.
- Die eigentliche Verarbeitung erfolgt synchron oder über eine interne Queue.
Warum Webhooks zuverlässig entworfen werden müssen
Netzwerke sind nicht perfekt. Ein Empfänger kann vorübergehend nicht erreichbar sein, eine Verbindung kann abbrechen oder ein Quellsystem kann dieselbe Zustellung erneut senden. Deshalb sollte Webhook-Verarbeitung nicht davon ausgehen, dass jedes Ereignis exakt einmal und immer in der erwarteten Reihenfolge ankommt.
Wichtige technische Konzepte sind:
- Retries: fehlgeschlagene Zustellungen erneut versuchen,
- Idempotenz: doppelte Verarbeitung darf nicht zu doppelten fachlichen Effekten führen,
- Event-ID: Zustellungen eindeutig erkennen,
- Queueing: Eingang und aufwendige Verarbeitung entkoppeln,
- Monitoring: fehlgeschlagene oder ungewöhnliche Zustellungen sichtbar machen.
Sicherheit: Eine öffentliche URL ist kein Vertrauensbeweis
Ein Webhook-Endpunkt ist häufig über das Internet erreichbar. Der Empfänger muss daher prüfen, ob eine Nachricht tatsächlich vom erwarteten System stammt. Anbieter verwenden dazu beispielsweise HMAC-Signaturen oder andere Verifikationsmechanismen.
Zusätzlich sollten TLS, Secret-Management, Payload-Validierung, minimale Berechtigungen und Schutz gegen Replay-Angriffe betrachtet werden. Ein Secret gehört nicht in Logs oder öffentlich erreichbaren Quellcode.
Webhook und API gehören oft zusammen
Ein Webhook transportiert häufig nur das Ereignis und einige Kerndaten. Danach kann der Empfänger per API weitere aktuelle Informationen abrufen. So lässt sich beispielsweise ein „Order updated“-Event empfangen und anschließend der vollständige Auftragsdatensatz über die API lesen.
Diese Kombination ist robust, weil der Webhook als Trigger dient und die API den aktuellen Zustand bereitstellt.
Typische Einsatzfälle
- Zahlung wurde erfolgreich verbucht,
- neuer Lead wurde angelegt,
- Dokument wurde freigegeben,
- Code wurde in ein Repository gepusht,
- Supportticket änderte seinen Status,
- neue Bestellung soll einen Folgeprozess starten.
Praxisbeispiel
Ein Onlineformular erzeugt einen qualifizierten Lead. Statt dass das CRM regelmäßig neue Einträge abfragt, kann der Formularservice einen Webhook senden. Ein Integrationsdienst validiert das Event, legt den Lead im CRM an und informiert das zuständige Team. Kommt dasselbe Event wegen eines Retries zweimal an, verhindert die Event-ID einen doppelten Lead.
Webhook-Verträge sollten versioniert werden
Ein Event-Payload ist ebenfalls eine Schnittstelle. Wenn ein Anbieter Felder entfernt oder deren Bedeutung ändert, können Empfängerprozesse ausfallen. Deshalb sollten Webhook-Schemata dokumentiert und Änderungen möglichst abwärtskompatibel eingeführt werden.
Auch Datenschutz spielt eine Rolle: Ein Webhook sollte nur die Daten transportieren, die der Empfänger für das Ereignis benötigt. Sensible Vollobjekte „vorsichtshalber“ mitzuschicken erhöht unnötig die Angriffs- und Datenschutzfläche.
Fazit
Webhooks sind ein einfacher Baustein für ereignisgetriebene Integrationen. Professionell werden sie erst durch Zuverlässigkeit, Sicherheitsprüfung, Idempotenz und Monitoring. Sie ersetzen APIs nicht, sondern ergänzen sie häufig um den entscheidenden Trigger.
Passende Leistungen von Wils Solutions
Häufige Fragen
Was ist der Unterschied zwischen API und Webhook?
Bei einer API startet der Client typischerweise eine Anfrage. Ein Webhook wird vom Quellsystem bei einem Ereignis automatisch an den Empfänger gesendet.
Ist ein Webhook immer HTTP?
Der Begriff wird heute überwiegend für HTTP-basierte Event-Callbacks verwendet.
Warum kann ein Webhook mehrfach ankommen?
Bei Netzwerk- oder Bestätigungsfehlern können Quellsysteme Zustellungen wiederholen. Empfänger sollten daher idempotent arbeiten.
Wie sichert man Webhooks ab?
Typisch sind HTTPS, Signaturprüfung, Secret-Management, Payload-Validierung, Replay-Schutz und Monitoring.