Ein Webhook ist üblicherweise ein HTTP-Callback: eine ereignisgesteuerte Benachrichtigung zwischen Systemen. Tritt in einem Quellsystem ein abonniertes Ereignis ein, sendet dieses Daten an eine zuvor hinterlegte URL des empfangenden Systems. Statt regelmäßig nach Änderungen zu fragen, erhält der Empfänger eine Nachricht, wenn etwas passiert. GitHub beschreibt dieses Prinzip als Zustellung von Daten an einen externen Server bei bestimmten Ereignissen und ordnet es dem Gegensatz zum Polling zu (GitHub Docs: About webhooks).
Statt alle paar Minuten nachzufragen: „Gibt es etwas Neues?“, hinterlässt ein System eine Adresse und sagt, für welche Ereignisse es sich interessiert. Das Quellsystem meldet sich dort, sobald ein Ereignis eintritt. Ein Webhook kann etwa informieren, dass ein Code-Stand geändert, eine Rechnung bezahlt oder ein Formular abgesendet wurde.
Diese Arbeitsweise passt besonders zu Abläufen, bei denen eine Reaktion zeitnah erfolgen soll. Sie ersetzt aber nicht jede Abfrage über eine Schnittstelle: Ein Empfänger braucht oft weiterhin eine API, um nach einer Benachrichtigung vollständige Details abzurufen oder einen verpassten Zustand abzugleichen. Der Webhook liefert vor allem den Anstoß, nicht zwangsläufig den gesamten fachlichen Kontext.
Bei der Einrichtung werden mindestens eine Ziel-URL und die gewünschten Ereignisse festgelegt. Tritt eines davon ein, erstellt das Quellsystem eine HTTP-Anfrage an diese URL. Die Nachricht enthält üblicherweise einen Ereignistyp und Nutzdaten, häufig als JSON. Wie genau Header, Format, Wiederholungen und Zeitlimits aussehen, ist vom jeweiligen Anbieter abhängig.
Der Empfänger stellt einen Endpunkt bereit, nimmt die Anfrage entgegen und führt seine fachliche Verarbeitung aus. Wichtig ist, schnell zu antworten und aufwendige Arbeiten gegebenenfalls in eine Warteschlange auszulagern. Denn Zustellungen können fehlschlagen, verzögert sein oder erneut eintreffen. Eine robuste Verarbeitung erkennt deshalb Doppelzustellungen und behandelt sie nicht ungewollt zweimal.
Ein Webhook sollte außerdem nicht allein deshalb vertraut werden, weil er eine bekannte URL erreicht. Anbieter können signierte Zustellungen vorsehen. Für GitHub wird eine Signatur mit einem gemeinsamen Secret erzeugt; die Dokumentation empfiehlt, die Signatur vor der weiteren Verarbeitung zu prüfen und das Secret nicht im Quellcode oder Repository zu hinterlegen (GitHub Docs: Validating webhook deliveries). Das genaue Prüfverfahren ist anbieterspezifisch.
Ein Entwicklungsteam verbindet ein Repository mit einem externen Dienst für automatisierte Prüfungen. Für das Ereignis „Code wurde in einen Branch übertragen“ ist ein Webhook eingerichtet. Nach dem Push sendet das Repository eine Nachricht an den Endpunkt des Prüfdienstes. Dieser prüft zunächst, ob die Nachricht authentisch ist, ordnet sie dem passenden Repository zu und startet anschließend einen Testlauf.
Damit nicht jeder Schritt durch regelmäßige Abfragen des Repositorys entdeckt werden muss, kommt der Impuls unmittelbar vom Ereignis. GitHub nennt das Auslösen externer CI-Pipelines nach einem Push als typischen Einsatzfall (GitHub Docs: About webhooks). In einer realen Umsetzung gehört jedoch auch dazu, Fehlversuche, Wiederholungen und den Fall zu behandeln, dass der Endpunkt zeitweise nicht erreichbar ist.
Webhooks verbinden Anwendungen in ereignisorientierten Abläufen. Häufige Beispiele sind Benachrichtigungen an Kommunikationsdienste, die Aktualisierung eines CRM-Systems nach einem Formularereignis, die Weitergabe von Zahlungsstatus oder die Auslösung von Tests und Bereitstellungen. Sie sind damit ein Baustein der Workflow-Automatisierung und arbeiten oft zusammen mit einer Application Programming Interface.
Auch Integrationsplattformen können Webhooks entgegennehmen und daraus weitere Schritte ableiten. Ob dafür Programmierung nötig ist, hängt vom System und vom Prozess ab. Entscheidend bleibt: Ereignis, Datenformat, Zielsystem und Fehlerbehandlung müssen fachlich zusammenpassen; ein Webhook automatisiert keine unklar definierte Aufgabe von selbst.
Ein Webhook ist keine universelle, standardisierte Schnittstelle. Ereignisnamen, Payloads, Signaturverfahren und Wiederholungslogik unterscheiden sich je nach Anbieter. Wer mehrere Anbieter integriert, muss deren jeweilige Dokumentation prüfen.
Ein weiterer Irrtum lautet, eine erfolgreiche HTTP-Antwort bedeute automatisch, dass der Geschäftsprozess abgeschlossen sei. Sie kann lediglich bestätigen, dass der Empfänger die Nachricht angenommen hat. Für verlässliche Abläufe braucht es Beobachtbarkeit, kontrollierte Wiederholungen und eine Möglichkeit zur Nachbearbeitung. Ebenso ist ein Webhook nicht automatisch „Echtzeit“ im streng technischen Sinn: Zustellung und Verarbeitung benötigen Zeit und können scheitern.
Eine Application Programming Interface beschreibt allgemein eine definierte Schnittstelle, über die Software Funktionen oder Daten nutzen kann. Ein Webhook ist dagegen ein konkretes Muster, bei dem das Quellsystem eine Nachricht an den Empfänger sendet. Beim Polling fragt der Empfänger aktiv in Intervallen nach Veränderungen; beim Webhook wird er bei einem Ereignis benachrichtigt. Beide Verfahren können in derselben Integration sinnvoll zusammenwirken.