Webhook
Ein Webhook ist eine automatische Benachrichtigung, die ein System per HTTP-Aufruf an ein anderes sendet, sobald ein zuvor definiertes Ereignis eintritt – etwa eine eingegangene Bestellung, eine abgeschlossene Zahlung oder eine erstellte Versand-Sendung.
Webhooks sind das Gegenstück zur klassischen API-Abfrage. Während APIs aktiv gefragt werden müssen, melden Webhooks Ereignisse selbständig – die Grundlage für Echtzeit-Integrationen zwischen Shop, Buchhaltung, Warenwirtschaft und externen Diensten.
In einfachen Worten
Eine klassische API funktioniert wie ein Telefon-Anruf: Eine Seite fragt aktiv nach Informationen. Ein Webhook funktioniert umgekehrt – wie eine Benachrichtigung, die ohne Nachfrage zugestellt wird. Sobald in einem System ein zuvor definiertes Ereignis eintritt (etwa eine neue Bestellung im Shop, eine Zahlung beim Bezahl-Anbieter, eine neue Lead-Anfrage), sendet das auslösende System die Daten unmittelbar an die hinterlegte Empfänger-Adresse. Empfänger ist in der Regel ein anderer Server, der die Daten weiterverarbeitet. Die Übertragung erfolgt über das HTTP-Protokoll, in der Regel im JSON-Format. Webhooks vermeiden die Reibungs-Verluste regelmäßiger Abfragen (Polling): keine eingebaute Verzögerung, keine unnötige Server-Last, keine verpassten Ereignisse zwischen zwei Abfrage-Zyklen.
Wozu brauche ich das?
Webhooks koppeln Systeme in Echtzeit. Typisches Szenario: Eine Bestellung im Shop löst innerhalb weniger Sekunden eine Rechnung in der Buchhaltungs-Software aus, ein Versand-Etikett beim Versanddienst, eine Bestätigungs-E-Mail an die Kundin oder den Kunden und einen Benachrichtigungs-Eintrag im Lager-System; im Content-Umfeld stößt ein veröffentlichter Beitrag im Headless CMS den Neuaufbau der Website an. Statt jedes dieser Folge-Systeme im Minuten-Takt abzufragen, erhält jedes die Information genau dann, wenn sie entsteht – mit drastisch geringerer Verzögerung und geringerer Last auf allen beteiligten Servern.
Beispiel aus der Praxis
Eine typische Konstellation: Ein klassisch aufgesetzter Bestell-Vorgang lässt eine nachgelagerte Buchhaltungs-Software alle paar Minuten neue Bestellungen aus dem Shop-Server abfragen. Dieses Polling-Verfahren erzeugt eingebaute Verzögerung und unnötige Server-Last – im Großteil der Abfragen liegt keine neue Bestellung vor. Mit einer Webhook-Anbindung dreht sich die Logik um: Sobald eine Bestellung im Shop angelegt wird, sendet das Shop-System die Daten aktiv an alle beteiligten Systeme – Buchhaltung, Lager, Versanddienst, Mail-Versand. Die Bestätigungs-E-Mail erreicht den Kunden binnen weniger Sekunden statt nach Minuten, das Lager wird parallel informiert, und es gibt keine doppelten oder verpassten Datensätze. Der Effekt skaliert mit der Anzahl beteiligter Systeme.
Wirtschaftlicher Nutzen
Webhooks reduzieren die Server-Last gegenüber regelmäßiger Abfrage erheblich, weil sie Informationen ausschließlich bei tatsächlichen Ereignissen übertragen. Sie ermöglichen Echtzeit-Prozesse, die mit klassischer Polling-Logik wirtschaftlich nicht darstellbar wären – besonders in E-Commerce, Buchungs-Systemen und Marketing-Automation. Im Kunden-Erlebnis macht sich die schnellere Reaktion direkt bemerkbar: Eine sofortige Bestätigung schafft Vertrauen, eine verspätete Bestätigung Unsicherheit. Die Investition in eine saubere Webhook-Anbindung ist meist überschaubar, der laufende Nutzen wirkt dauerhaft.
Typische Fehler
- Empfänger-Adresse nicht abgesichert – ohne Signatur-Prüfung kann jede beliebige Seite gefälschte Ereignisse einspielen.
- Keine Idempotenz vorgesehen – ein doppelt zugestellter Webhook löst zweimal eine Bestellung, eine Rechnung oder einen Versand aus.
- Verarbeitung dauert zu lange – das sendende System gibt nach wenigen Sekunden auf und betrachtet die Zustellung als fehlgeschlagen.
- Kein Wiederholungs-Mechanismus auf der Empfänger-Seite – wenn der eigene Server kurz nicht erreichbar war, gehen Ereignisse verloren.
- Kein Protokoll der eingehenden Ereignisse geführt – im Fehlerfall lässt sich nicht mehr nachvollziehen, welche Webhooks wann eingegangen sind.
Worauf achten?
- Der Empfänger muss zuverlässig erreichbar sein – Ausfälle führen ohne Wiederholungs-Mechanismus direkt zum Daten-Verlust.
- Wiederholungen und Fehler-Behandlung von Anfang an einplanen – sowohl auf der Sender- als auch auf der Empfänger-Seite.
- Signaturen prüfen, damit ausschließlich der berechtigte Absender Daten in die eigene Verarbeitung einspielen kann, und den Empfangs-Endpunkt zusätzlich über Security-Header härten.
- Eingehende Webhooks protokollieren – ohne diese Spur ist eine Fehler-Analyse im Streitfall sehr aufwändig.
- Empfangs-Logik schlank halten: erst die Zustellung mit Statuscode 200 bestätigen, dann die eigentliche Verarbeitung anstoßen (in der Regel asynchron).
Häufig gestellte Fragen
Was ist ein Webhook?
Eine automatische Benachrichtigung per HTTP-Aufruf, die ein System an ein anderes sendet, sobald ein zuvor definiertes Ereignis eintritt. Im Unterschied zur klassischen API-Abfrage muss die Empfänger-Seite nicht aktiv nach neuen Informationen fragen.
Worin unterscheidet sich ein Webhook von einer API?
Eine API wird aktiv abgefragt; ein Webhook wird passiv empfangen. Beide nutzen das HTTP-Protokoll, aber die Richtung ist entgegengesetzt: Bei der API initiiert die fragende Seite, beim Webhook initiiert die ereignis-auslösende Seite. In der Praxis ergänzen sich beide Verfahren häufig.
Welche Sicherheits-Aspekte sind zentral?
Signatur-Prüfung der eingehenden Ereignisse, sodass ausschließlich der berechtigte Absender Daten in die eigene Verarbeitung einspielen kann; abgesicherte Empfänger-Adresse, idealerweise nicht öffentlich erratbar; vollständiges Protokoll für die spätere Nachverfolgbarkeit.
Was bedeutet Idempotenz bei Webhooks?
Idempotenz bedeutet, dass eine wiederholte Ausführung desselben Ereignisses dasselbe Ergebnis liefert wie eine einmalige. Webhooks können in Ausnahme-Fällen doppelt zugestellt werden; ohne Idempotenz löst eine Doppel-Zustellung zwei Bestellungen, zwei Rechnungen oder zwei Versand-Aufträge aus.
Wann ist ein Webhook einer API-Abfrage vorzuziehen?
Sobald die zu übertragenden Ereignisse zeitkritisch sind und unregelmäßig auftreten. Wer alle paar Minuten nach neuen Daten fragt, verschwendet Ressourcen und nimmt eine eingebaute Verzögerung in Kauf; ein Webhook überträgt sofort und ausschließlich dann, wenn tatsächlich ein Ereignis vorliegt.