Ein Webhook ist ein automatisierter HTTP-Rückruf (engl. HTTP-Callback), mit dem ein System ein anderes System in dem Moment benachrichtigt, in dem ein bestimmtes Ereignis eintritt. Statt dass die empfangende Anwendung in regelmäßigen Abständen nachfragt „Gibt es etwas Neues?“, schickt das auslösende System bei jedem relevanten Ereignis von sich aus eine HTTP-Anfrage an eine zuvor hinterlegte URL. Ein Webhook funktioniert damit nach dem Push-Prinzip: Die Information wird aktiv zugestellt, sobald sie entsteht, und nicht erst beim nächsten Abruf abgeholt. Genau dieses Push-Verhalten macht Webhooks zu einem der wichtigsten Bausteine moderner Systemintegration und Automatisierung.
Der Begriff selbst beschreibt das Prinzip recht treffend: Ein „Hook“ (Haken) ist eine Stelle im Programmablauf, an der du eigenen Code einklinken kannst. Ein Webhook verlegt diesen Einklink-Punkt ins Web – statt einer Funktion im selben Programm wird eine fremde URL über das Internet aufgerufen. Du hinterlegst beim auslösenden Dienst einmalig eine Adresse, und ab diesem Zeitpunkt ruft der Dienst diese Adresse bei jedem passenden Ereignis auf. Der populäre Programmierer Jeff Lindsay hat den Begriff um 2007 geprägt, und seitdem hat sich das Konzept als De-facto-Standard für ereignisgetriebene Benachrichtigungen zwischen Webdiensten etabliert.
Webhook vs. Polling: Push statt ständigem Nachfragen
Um zu verstehen, warum Webhooks so verbreitet sind, lohnt sich der Vergleich mit dem klassischen Gegenmodell, dem Polling. Beim Polling fragt ein System in festen Intervallen aktiv beim anderen System nach, ob sich etwas geändert hat – etwa alle 30 Sekunden, jede Minute oder jede Stunde. Dieses Vorgehen ist einfach umzusetzen, hat aber zwei strukturelle Nachteile: Es erzeugt unnötige Last, weil die allermeisten Abfragen ergebnislos bleiben, und es ist immer einen Intervall-Zeitraum zu langsam, weil eine Änderung erst beim nächsten Abruf bemerkt wird.
Der Webhook dreht dieses Verhältnis um. Nicht der Empfänger fragt, sondern der Sender meldet sich von selbst – und zwar genau dann, wenn es etwas zu melden gibt. Das spart Ressourcen auf beiden Seiten und liefert die Information nahezu in Echtzeit. Die folgende Übersicht stellt beide Ansätze gegenüber.
| Kriterium | Webhook (Push) | Polling (Pull) |
|---|---|---|
| Auslöser | Ereignis im Quellsystem | Zeitintervall im Zielsystem |
| Aktualität | nahezu in Echtzeit | verzögert um das Abfrageintervall |
| Ressourcenverbrauch | gering, nur bei echten Ereignissen | hoch, viele leere Abfragen |
| Komplexität Empfänger | muss erreichbaren Endpunkt bereitstellen | einfacher Client, kein Endpunkt nötig |
| Eignung | seltene, aber zeitkritische Ereignisse | einfache, gleichmäßige Datenabgleiche |
In der Praxis schließen sich beide Verfahren nicht aus. Viele robuste Integrationen nutzen Webhooks als schnellen Echtzeit-Kanal und ergänzen sie um ein gelegentliches Polling als Sicherheitsnetz, falls einzelne Webhook-Zustellungen verloren gehen.
Webhook vs. API: zwei Seiten derselben Medaille
Webhook und API werden gern verwechselt, sind aber komplementäre Konzepte. Eine klassische API (genauer: eine Request-Response-API) wartet passiv, bis ein Client eine Anfrage stellt, und antwortet dann. Die Initiative liegt beim Aufrufer. Ein Webhook kehrt diese Richtung um: Hier ist das System, das sonst die API bereitstellt, der aktive Sender, und dein eigener Endpunkt ist der Empfänger. Man spricht deshalb gelegentlich von einer „Reverse API“.
Ein anschaulicher Vergleich: Eine API ist wie ein Telefon, bei dem du anrufst, wenn du etwas wissen willst. Ein Webhook ist wie ein Benachrichtigungsdienst, der dich von sich aus anruft, sobald etwas passiert. Beide nutzen dieselbe technische Grundlage – HTTP –, unterscheiden sich aber darin, wer den Anstoß gibt. In der Realität arbeiten beide oft zusammen: Ein Webhook meldet dir, dass etwas passiert ist, und du rufst anschließend per API die vollständigen Details ab.
Wie ein Webhook technisch aufgebaut ist
Technisch ist ein Webhook erfreulich unspektakulär, und genau das ist seine Stärke. Das auslösende System sendet beim Eintreten eines Ereignisses eine HTTP-Anfrage – in aller Regel ein POST-Request – an die von dir hinterlegte URL. Der Inhalt dieser Anfrage, der sogenannte Payload, beschreibt das Ereignis. Heute ist dieser Payload fast immer im JSON-Format formuliert.
Ein typischer Webhook-Aufruf für eine neu eingegangene Bestellung könnte beispielsweise so aussehen:
POST /webhooks/bestellung HTTP/1.1
Host: deine-anwendung.de
Content-Type: application/json
X-Signature: sha256=8f3b2c...
{
"event": "order.created",
"id": "ord_10482",
"kunde": "kunde@example.com",
"betrag": 149.90,
"waehrung": "EUR",
"zeitpunkt": "2026-06-05T09:14:22Z"
}Dein Endpunkt empfängt diese Anfrage, liest den Payload aus und stößt die passende Reaktion an – etwa eine Bestellbestätigung verschicken, den Datensatz ins ERP schreiben oder eine interne Benachrichtigung auslösen. Wichtig ist, dass dein Endpunkt schnell mit einem HTTP-Statuscode im 2xx-Bereich antwortet, um den erfolgreichen Empfang zu quittieren. Aufwendige Verarbeitung solltest du in einen Hintergrundprozess auslagern, damit die Antwort an den Absender nicht ins Timeout läuft.
Typischer Payload und Header
Neben dem eigentlichen JSON-Körper transportiert ein Webhook meist mehrere aussagekräftige HTTP-Header. Üblich sind ein Header, der den Ereignistyp benennt (etwa order.created oder payment.succeeded), eine eindeutige Ereignis-ID zur Erkennung von Duplikaten sowie ein Signatur-Header zur Verifizierung der Echtheit. Der Ereignistyp erlaubt es deinem Endpunkt, eine einzige URL für viele verschiedene Ereignisse zu nutzen und je nach Typ unterschiedlich zu reagieren.
Sicherheit: Warum Verifizierung Pflicht ist
Ein Webhook-Endpunkt ist per Definition öffentlich erreichbar – sonst könnte der absendende Dienst ihn nicht aufrufen. Damit ist er aber auch für Unbefugte erreichbar. Jeder, der die URL kennt oder errät, könnte gefälschte Anfragen schicken. Deshalb ist die Verifizierung eingehender Webhooks kein optionales Extra, sondern Grundvoraussetzung für einen produktiven Einsatz.
Der verbreitetste Mechanismus ist die Signaturprüfung per HMAC. Dabei vereinbaren Sender und Empfänger einmalig ein geheimes Secret. Der Sender berechnet aus dem Payload und diesem Secret eine kryptografische Signatur (oft HMAC-SHA256) und legt sie als Header bei. Dein Endpunkt berechnet dieselbe Signatur mit demselben Secret nach und vergleicht beide Werte. Stimmen sie überein, ist sichergestellt, dass die Anfrage tatsächlich vom erwarteten Absender stammt und unterwegs nicht verändert wurde. Stimmen sie nicht, verwirfst du die Anfrage.
- Secret geheim halten: Das Secret gehört in eine sichere Konfiguration, niemals in den Quellcode oder ins Frontend.
- Signatur immer prüfen: Verarbeite keinen Payload, dessen Signatur du nicht verifiziert hast.
- HTTPS erzwingen: Webhook-Endpunkte sollten ausschließlich über TLS erreichbar sein, damit der Payload nicht im Klartext über das Netz geht.
- Zeitstempel berücksichtigen: Ein mitgesendeter Zeitstempel hilft, alte abgefangene Anfragen (Replay-Angriffe) abzuwehren.
Wer diese Grundregeln befolgt, schließt die häufigsten Sicherheitslücken bei der Webhook-Verarbeitung von vornherein aus.
Retries und Idempotenz
Webhooks werden über das offene Internet zugestellt, und Zustellungen können fehlschlagen – etwa weil dein Server kurz nicht erreichbar war. Seriöse Anbieter wiederholen die Zustellung deshalb automatisch (Retries), meist mit wachsenden Abständen über Stunden oder Tage hinweg, bis dein Endpunkt einen Erfolgs-Statuscode zurückgibt. Diese Wiederholungen sind eine Stärke, bringen aber eine Konsequenz mit sich: Dasselbe Ereignis kann mehrfach bei dir ankommen.
Die Antwort darauf heißt Idempotenz. Dein Endpunkt muss so gebaut sein, dass die mehrfache Verarbeitung desselben Ereignisses denselben Effekt hat wie die einmalige. In der Praxis erreichst du das, indem du die mitgelieferte eindeutige Ereignis-ID speicherst und jede ID nur einmal verarbeitest. Trifft ein bereits bekanntes Ereignis erneut ein, quittierst du den Empfang, führst die Aktion aber nicht ein zweites Mal aus. So vermeidest du Doppelbuchungen, doppelte E-Mails oder doppelte Datensätze.
Typische Einsatzfälle
Webhooks sind heute aus der Software-Landschaft kaum wegzudenken. Sie verbinden Dienste, die sich sonst nichts voneinander wüssten, und sind das Rückgrat vieler Echtzeit-Automatisierungen. Einige der häufigsten benannten Beispiele:
- Stripe verschickt Webhook-Events wie
payment_intent.succeededoderinvoice.paid, damit dein Shop auf erfolgreiche Zahlungen reagieren kann, ohne den Zahlungsstatus aktiv abfragen zu müssen. Die Webhook-Dokumentation von Stripe gilt vielen als Referenz für sauberes Webhook-Design inklusive Signaturprüfung. - GitHub Webhooks benachrichtigen externe Systeme bei Ereignissen wie einem
push, einem geöffnetenpull_requestoder einem neuenissue– die Grundlage vieler CI/CD-Pipelines und Deployment-Automatisierungen. - Slack Incoming Webhooks erlauben es, mit einem einfachen POST-Request Nachrichten in einen Slack-Kanal zu posten – ein beliebter Weg, um Alarme und Statusmeldungen automatisiert ins Team zu spielen.
- Shopify Webhooks melden Ereignisse wie
orders/createoderproducts/updatean angebundene Systeme, etwa um Bestellungen direkt in ein ERP oder Fulfillment-System zu übergeben.
Diese Beispiele zeigen das gemeinsame Muster: Ein Ereignis in System A löst über einen Webhook unmittelbar eine Reaktion in System B aus, ohne dass ein Mensch oder ein Abfragezyklus dazwischenstehen muss.
Webhooks in No-Code-Tools wie n8n, Make und Zapier
Ihre volle Breitenwirkung entfalten Webhooks im Zusammenspiel mit No-Code- und Low-Code-Automatisierungsplattformen. Werkzeuge wie n8n, Make und Zapier stellen einen Webhook-Knoten bereit, der dir mit wenigen Klicks eine eindeutige Empfangs-URL erzeugt. Diese URL hinterlegst du beim auslösenden Dienst – und schon startet jeder eingehende Webhook einen kompletten Automatisierungs-Workflow, ganz ohne eigenen Servercode.
Damit werden Webhooks zum universellen Auslöser (Trigger) für Automatisierungen: Eine eingehende Bestellung, ein ausgefülltes Formular oder eine erfolgreiche Zahlung stößt per Webhook eine Kette von Schritten an – Daten anreichern, in ein anderes System schreiben, eine Benachrichtigung verschicken. Genau auf diesem Prinzip baut ein Großteil der Prozessautomatisierung & KI-Workflows auf, die wir umsetzen. Ein praktisches Beispiel ist eine automatische Alarmierung mit n8n, bei der ein eingehender Webhook eine sofortige Benachrichtigung an das zuständige Team auslöst.
Der Charme dieses Ansatzes liegt darin, dass du das mächtige Push-Prinzip der Webhooks nutzt, ohne selbst einen Endpunkt programmieren, absichern und betreiben zu müssen – die Plattform übernimmt Empfang, Signaturprüfung und Weiterverarbeitung. Für viele mittelständische Automatisierungen ist das der schnellste Weg von einem Ereignis zu einer verlässlichen, wiederholbaren Reaktion.
Häufige Fragen
Was ist der Unterschied zwischen einem Webhook und einer API?
Bei einer klassischen API fragst du aktiv Daten ab – die Initiative liegt bei dir. Bei einem Webhook meldet sich das andere System von selbst, sobald ein Ereignis eintritt. Ein Webhook ist also gewissermaßen eine umgekehrte API: Statt zu fragen, wirst du benachrichtigt. Beide nutzen HTTP und werden in der Praxis oft kombiniert.
Brauche ich einen eigenen Server für Webhooks?
Nicht zwingend. Zwar musst du einen über das Internet erreichbaren Endpunkt bereitstellen, doch No-Code-Plattformen wie n8n, Make oder Zapier liefern diesen Endpunkt fertig mit. Du erhältst eine Empfangs-URL und kannst die Verarbeitung ohne eigenen Servercode aufbauen.
Wie sichere ich einen Webhook gegen Missbrauch ab?
Der wichtigste Schutz ist die Signaturprüfung per HMAC mit einem geheimen Secret: Du berechnest die mitgesendete Signatur nach und verwirfst alle Anfragen, deren Signatur nicht passt. Ergänzend solltest du ausschließlich HTTPS zulassen, das Secret sicher verwahren und über einen Zeitstempel Replay-Angriffe abwehren.
Was passiert, wenn mein Endpunkt einen Webhook nicht annimmt?
Seriöse Anbieter wiederholen die Zustellung automatisch über einen längeren Zeitraum, bis dein Endpunkt mit einem Erfolgs-Statuscode antwortet. Weil dadurch dasselbe Ereignis mehrfach eintreffen kann, sollte dein Endpunkt idempotent sein und jede Ereignis-ID nur einmal verarbeiten.
Wofür wird ein Webhook in der Automatisierung genutzt?
In Automatisierungsplattformen dient der Webhook meist als Auslöser: Ein Ereignis in einem Quellsystem – eine Bestellung, ein Formular, eine Zahlung – startet über die Webhook-URL einen kompletten Workflow, der anschließend Daten verarbeitet, weiterleitet oder Benachrichtigungen verschickt.