Webhook einfach erklärt: Ereignisse statt regelmäßiger Abfragen

Das Problem: unnötige Abfragen statt echter Ereignisse

Ein Muster, das mir in Integrationsprojekten ständig begegnet: Ein Workflow fragt alle fünf Minuten bei einem anderen System nach, ob sich etwas geändert hat – Bestellungen, Tickets, neue Datensätze. In den allermeisten Fällen lautet die Antwort „nein”. Das kostet unnötige API-Aufrufe, verbraucht Rate-Limit-Kontingente und liefert neue Daten trotzdem erst mit Verzögerung, weil dazwischen ja gewartet wird. Dabei bieten viele Systeme längst eine bessere Lösung an: Sie melden sich selbst, sobald etwas passiert.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die in Automatisierungstools wie n8n, Make oder Zapier immer wieder über „Webhook” stolpern und wissen wollen, was sich dahinter verbirgt, wie sich das von einer normalen API-Abfrage unterscheidet, wie ein Webhook abgesichert wird, was bei Ausfällen passiert – und wann Polling trotzdem die richtige Wahl bleibt. Er ist Teil unserer Übersicht zu Automatisierungstools und Integrationen.

Begriffe kurz geklärt

• Webhook: Eine vom Zielsystem bereitgestellte URL, an die ein anderes System eine HTTP-Anfrage (meist POST) mit Daten schickt, sobald ein definiertes Ereignis eintritt.
• Payload: Der eigentliche Dateninhalt der Webhook-Nachricht, meist als JSON.
• Endpoint: Die konkrete Adresse, an der ein System eingehende Anfragen entgegennimmt – beim Webhook also die vom Empfänger bereitgestellte URL.
• Polling: Aktives, wiederholtes Nachfragen in festen Zeitabständen, ob sich Daten geändert haben – die Umkehrung des Webhook-Prinzips.
• Trigger: In Automatisierungstools wie n8n der Baustein, der einen Workflow startet – ein Webhook-Trigger reagiert auf eingehende Anfragen, ein Polling-Trigger fragt nach Zeitplan ab.

Was ist ein Webhook?

Ein Webhook ist im Kern eine automatisierte HTTP-Benachrichtigung von System zu System. Das Empfängersystem stellt eine eindeutige URL bereit; das Quellsystem hinterlegt diese URL einmalig in seiner Konfiguration. Tritt danach ein bestimmtes Ereignis ein – eine neue Bestellung, ein aktualisierter Datensatz, eine abgeschlossene Zahlung –, schickt die Quelle automatisch eine Anfrage mit den relevanten Daten an genau diese URL.

n8n beschreibt den eigenen Webhook-Node entsprechend als Baustein, der Workflows „aus Diensten auslöst, die keinen eigenen App-Trigger-Node haben” – also überall dort, wo ein System zwar HTTP-Anfragen senden kann, aber keine fertige Integration existiert. Technisch generiert n8n dafür zwei unterschiedliche URLs: eine Test-URL, die beim manuellen Ausführen des Workflows aktiv ist, und eine separate Produktions-URL, die erst beim Veröffentlichen des Workflows registriert wird. Für die Antwort an den Absender stehen mehrere Modi zur Wahl – sofort antworten, erst nach Abschluss des letzten Workflow-Schritts, über einen eigenen „Respond to Webhook”-Baustein oder als laufender Datenstrom.

Das Prinzip ist plattformübergreifend gleich, auch wenn die Umsetzung variiert. Make unterscheidet in der eigenen Dokumentation explizit zwischen App-spezifischen Webhooks (die auf Ereignisse eines bestimmten Dienstes reagieren) und Custom Webhooks, bei denen eine beliebige externe Quelle Daten an eine selbst erzeugte URL senden kann.

Wie unterscheidet er sich von einer API-Abfrage?

Der Unterschied liegt in der Richtung und im Auslöser. Bei einer klassischen API-Abfrage – Polling – ist dein System aktiv: Es ruft in festen Abständen einen Endpunkt auf und fragt „gibt es etwas Neues?”. Make beschreibt das treffend als Gegensatz zum Webhook: „geplante Trigger fragen periodisch einen Dienst nach neuen Daten ab”, während Webhooks „die Ausführung unmittelbar nach Empfang einer Anfrage” starten. Beim Webhook liegt die Initiative bei der Quelle, nicht beim Empfänger.

Merkmal	Webhook	API-Abfrage (Polling)
Wer initiiert die Anfrage?	Das Quellsystem, beim Eintreten des Ereignisses	Dein System, nach festem Zeitplan
Aktualität	Nahezu in Echtzeit	Verzögert um das Abfrageintervall
Anzahl unnötiger Anfragen	Keine – jede Anfrage trägt echte Daten	Hoch – die meisten Abfragen liefern „nichts Neues”
Voraussetzung	Anbieter unterstützt Webhooks, Endpunkt ist öffentlich erreichbar	Funktioniert mit jeder API, die Lesezugriff erlaubt
Risiko bei Ausfall des Empfängers	Nachricht kann verloren gehen, wenn der Anbieter nicht erneut zustellt	Nächster Abfragezyklus holt die Daten automatisch nach
Typischer Einsatz	Ereignisgetriebene Prozesse: Bestellung, Zahlung, Statuswechsel	Systeme ohne Webhook-Unterstützung, Abgleich in großen Intervallen

Eigene Gegenüberstellung Philogic Labs, basierend auf den Herstellerdokumentationen von n8n und Make.

Für die Praxis heißt das: Webhooks sind effizienter und schneller, sobald ein Anbieter sie zuverlässig unterstützt. Sie ersetzen Polling aber nicht in jedem Fall – dazu unten mehr.

Wie wird ein Webhook abgesichert?

Ein Webhook-Endpunkt ist eine öffentlich erreichbare URL, die Daten entgegennimmt und meist eine Aktion auslöst – im Grunde eine sehr kleine eigene Web-Schnittstelle. Der IT-Grundschutz-Baustein APP.3.1 des BSI formuliert das Ziel für Webanwendungen und Webservices allgemein so: Sie sollen „sicher eingesetzt” werden und die Informationen, die durch sie verarbeitet werden, geschützt sein. Für einen Webhook-Endpunkt lässt sich das in vier konkrete Maßnahmen übersetzen:

1. Authentifizierung des Absenders. Ohne Prüfung, wer da sendet, kann jeder, der die URL kennt oder errät, Daten einschleusen oder Workflows auslösen. n8n bietet für eingehende Webhooks beispielsweise vier Optionen: Basic Auth, Header Auth, JWT Auth oder keine Authentifizierung. Für produktive Endpunkte gehört „keine” nicht zur Auswahl.
2. Transportverschlüsselung. Die Anfrage läuft über HTTPS, nicht über unverschlüsseltes HTTP – sonst lassen sich Payload und eventuelle Zugangsdaten im Header mitlesen.
3. IP-Einschränkung, wo möglich. Wenn der Absender aus einem bekannten, festen IP-Bereich sendet, lässt sich der Zugriff zusätzlich eingrenzen. n8n bietet dafür eine IP-Allowlist an: Anfragen von nicht gelisteten Adressen werden mit HTTP 403 abgewiesen. Das funktioniert nicht bei jedem Anbieter, ist aber eine wirksame zusätzliche Hürde, wo verfügbar.
4. Eingangsprüfung statt Blindvertrauen. Jede eingehende Payload sollte auf Plausibilität geprüft werden, bevor sie in nachgelagerte Systeme übernommen wird – Pflichtfelder vorhanden, Format korrekt, Werte im erwarteten Bereich. Ein Webhook ist eine externe Eingabe wie jede andere auch und verdient dasselbe Misstrauen.

Ergänzend begrenzen viele Plattformen die Größe eingehender Nachrichten: Der n8n-Webhook-Node akzeptiert maximal 16 MB pro Payload. Wer größere Dateien überträgt, sollte ohnehin nicht die Datei selbst, sondern eine Referenz-URL im Payload mitschicken.

Was passiert bei Ausfällen?

Hier unterscheiden sich Anbieter deutlich, und genau das ist der wunde Punkt vieler Webhook-Integrationen: Ist der Zielsystem-Endpunkt kurzzeitig nicht erreichbar – Wartungsfenster, Timeout, Deployment –, entscheidet allein die Quelle, was mit der Nachricht passiert.

Make dokumentiert für die eigenen Custom Webhooks ein konkretes Verhalten: Bei sofortigen Webhooks stoppt die Verarbeitung nach drei erfolglosen Zustellversuchen; bei geplanten Webhooks wird das betroffene Szenario nach drei erfolglosen Versuchen deaktiviert. Zusätzlich begrenzt Make die Verarbeitungsgeschwindigkeit – laut eigener Dokumentation werden bis zu 300 eingehende Webhook-Anfragen pro Zehn-Sekunden-Intervall angenommen, darüber hinausgehende Anfragen erhalten den Fehlercode 429. Auch die Warteschlange selbst ist begrenzt: Je nach gebuchtem Kontingent passen laut Make bis zu einige Hundert bis maximal 10.000 Einträge in eine Webhook-Queue.

Das zeigt das grundsätzliche Muster:

Normalfall:
  [Quelle] --Ereignis--> [Webhook-Endpunkt] --200 OK--> fertig

Kurzer Ausfall, mit Retry-Unterstützung:
  [Quelle] --Ereignis--> [Endpunkt nicht erreichbar]
  [Quelle] --Retry 1, wachsender Abstand--> [Endpunkt] --200 OK--> fertig

Ausfall ohne ausreichende Retry-Unterstützung:
  [Quelle] --Ereignis--> [Endpunkt nicht erreichbar]
  [Quelle] --wenige Retries--> [Endpunkt weiter nicht erreichbar]
  --> Nachricht verworfen, niemand wird informiert

Für die Praxis folgen daraus zwei Konsequenzen. Erstens: Vor dem produktiven Einsatz prüfen, wie oft und wie lange der jeweilige Anbieter erneut zustellt – diese Angabe steht in der Anbieterdokumentation, nicht in einer allgemeinen Regel, denn sie unterscheidet sich von Dienst zu Dienst. Zweitens: Auf der Empfängerseite selbst vorsorgen, unabhängig davon, was die Quelle tut – mit einer Fehlerbehandlung, die fehlgeschlagene Verarbeitungen protokolliert und eine verantwortliche Person benachrichtigt, statt stillschweigend Daten zu verlieren. Ein Webhook, der „meistens” funktioniert und bei dem niemand merkt, wenn er es einmal nicht tut, ist riskanter als eine Abfrage, die zuverlässig, aber langsam ist.

Wann ist Polling nötig?

Webhooks sind nicht in jeder Situation die bessere Wahl. Polling bleibt die richtige Lösung, wenn mindestens einer dieser Punkte zutrifft:

• Der Anbieter unterstützt keine Webhooks. Viele ältere oder einfache Systeme bieten ausschließlich lesende API-Endpunkte an. Dann bleibt nur die regelmäßige Abfrage.
• Vollständigkeit ist wichtiger als Aktualität. Wenn du garantiert keine Ereignisse verpassen darfst und der Anbieter keine belastbare Zustellungsgarantie für Webhooks gibt, ist eine Abfrage, die den kompletten Datenbestand seit dem letzten Lauf abgleicht, robuster als das Vertrauen auf jede einzelne Zustellung.
• Das Intervall ist ohnehin groß. Für einen täglichen Datenabgleich, etwa einen nächtlichen Abstimmungslauf zwischen zwei Systemen, lohnt sich der zusätzliche Aufwand eines abgesicherten Webhook-Endpunkts oft nicht – eine geplante Abfrage einmal am Tag ist einfacher zu bauen und zu warten.
• Es fehlt die Infrastruktur für einen erreichbaren Endpunkt. Ein Webhook-Empfänger muss dauerhaft und öffentlich erreichbar sein. Wo das aus Sicherheits- oder Netzwerkgründen nicht gewollt ist, ist Polling gegen ein internes System oft die pragmatischere Variante.

In der Praxis kombiniere ich beides häufig: Webhook für die zeitkritischen, ereignisgetriebenen Fälle, dazu ein täglicher oder wöchentlicher Polling-Abgleich als Sicherheitsnetz, der verpasste oder nicht zugestellte Ereignisse nachträglich einfängt. Wer sich ausschließlich auf Webhooks verlässt, baut einen blinden Fleck ein, sobald die Zustellung einmal scheitert.

Umsetzung: Webhook einrichten und testen

So gehe ich in Automatisierungsprojekten typischerweise vor:

1. Anbieterdokumentation prüfen. Unterstützt das Quellsystem Webhooks? Welche Ereignisse lassen sich abonnieren? Wie verhält sich der Anbieter bei Zustellfehlern – Anzahl der Retries, Zeitfenster, gibt es überhaupt welche?
2. Endpunkt in der Middleware anlegen. In n8n etwa über den Webhook-Node: zunächst mit der Test-URL arbeiten, erst nach erfolgreichem Testlauf auf die Produktions-URL umstellen.
3. Absicherung konfigurieren, bevor die URL geteilt wird. Authentifizierungsmethode wählen (Header Auth oder JWT sind für die meisten Fälle praktikabler als Basic Auth), IP-Allowlist setzen, falls die Quelle feste Absenderadressen hat.
4. Payload-Validierung einbauen. Prüfen, ob Pflichtfelder vorhanden und Formate plausibel sind, bevor die Daten weiterverarbeitet werden.
5. Fehlerpfad definieren. Was passiert, wenn die Verarbeitung nach Empfang scheitert – Protokollierung, Benachrichtigung, ggf. ein Wiederholungsmechanismus auf der eigenen Seite.
6. Mit echten Testereignissen prüfen. Nicht nur ein manuell gebautes Test-Payload, sondern – wo möglich – ein echtes Ereignis aus dem Quellsystem auslösen und den kompletten Weg bis zur Zielanwendung verfolgen.

Als grobe Einordnung aus eigener Projekterfahrung, nicht als Zusage: Das reine Einrichten eines einzelnen, gut dokumentierten Webhooks in einer Middleware wie n8n ist meist eine Sache von Stunden. Aufwändiger wird es, sobald Absicherung, Payload-Validierung, Fehlerbehandlung und ein Polling-Sicherheitsnetz dazukommen – dann bewegt sich ein sauber gebauter Webhook-Prozess eher im Bereich von ein bis wenigen Tagen, abhängig davon, wie viele Sonderfälle die Payload-Daten mitbringen.

Risiken & Grenzen

• Die öffentliche Erreichbarkeit ist zugleich Stärke und Schwachstelle. Ein Webhook-Endpunkt muss von außen ansprechbar sein – das ist sein Zweck, aber auch sein größtes Risiko, wenn Authentifizierung und Validierung fehlen.
• Zustellung ist kein Naturgesetz. Wie oben beschrieben, garantieren nicht alle Anbieter eine zuverlässige erneute Zustellung. Ohne eigenes Monitoring bemerkst du verlorene Ereignisse oft erst, wenn ein Kunde nach einer fehlenden Bestellung fragt.
• Reihenfolge ist nicht garantiert. Bei paralleler Verarbeitung mehrerer eingehender Webhooks (der von Make beschriebene Standardmodus) können Ereignisse in anderer Reihenfolge verarbeitet werden, als sie entstanden sind. Wo Reihenfolge zählt, braucht es sequenzielle Verarbeitung oder eine Sortierung nach Zeitstempel im Payload.
• Testen ist unbequemer als bei Polling. Ein Webhook lässt sich nicht einfach manuell „anstoßen” wie eine API-Abfrage – man braucht entweder ein echtes Testereignis beim Anbieter oder ein simuliertes Payload, das der Realität entspricht.
• Kein Ersatz für fachliche Klärung. Ein Webhook liefert Rohdaten zum Zeitpunkt eines Ereignisses. Was danach damit passiert – Dublettenprüfung, Validierung, Zuordnung – ist dieselbe fachliche Arbeit wie bei jeder anderen Integration auch.

Checkliste: Webhook einrichten und absichern

1. Anbieterdokumentation geprüft: Welche Ereignisse, welches Retry-Verhalten bei Zustellfehlern?
2. Test-Endpunkt eingerichtet und mit echtem oder realistischem Payload geprüft.
3. Authentifizierung aktiv (Header Auth, JWT oder gleichwertig) – nicht „ohne”.
4. Verbindung läuft ausschließlich über HTTPS.
5. IP-Allowlist gesetzt, sofern die Quelle feste Absenderadressen nutzt.
6. Eingehende Payloads werden vor der Weiterverarbeitung validiert (Pflichtfelder, Format, Plausibilität).
7. Fehlerpfad definiert: Protokollierung, Benachrichtigung, ggf. eigener Retry.
8. Reihenfolge- und Dublettenverhalten geklärt, falls für den Prozess relevant.
9. Polling-Sicherheitsnetz eingeplant, wenn Vollständigkeit unverzichtbar ist.
10. Verantwortliche Person benannt, die Fehlermeldungen tatsächlich anschaut.

Wer diese zehn Punkte abhaken kann, hat einen Webhook, dem man auch geschäftskritische Prozesse anvertrauen kann – nicht nur eine Demo, die im Test funktioniert hat. Wenn ihr unsicher seid, ob euer Anwendungsfall überhaupt einen Webhook braucht oder ob Polling die robustere Wahl ist: Das ist genau die Art Frage, die in ein kurzes Erstgespräch gehört, bevor gebaut wird – ebenso wie unsere KI- und Automatisierungsberatung, wenn der Webhook Teil eines größeren Integrationsprojekts ist.