Webhooks verstehen: Wie Systeme in Echtzeit miteinander sprechen

Wenn ein Online-Shop eine Bestellung erhält und Sekunden später eine Rechnung in der Buchhaltung liegt, steckt meist ein Webhook dahinter. Der Begriff taucht in jeder Automatisierung auf, wird aber selten erklärt. Dieser Beitrag beschreibt, wie Webhooks funktionieren, wann sie die richtige Wahl sind und an welchen Stellen sie im Betrieb Probleme machen.

Das Prinzip: Bescheid sagen statt nachfragen

Es gibt zwei Wege, wie ein System von Änderungen in einem anderen erfährt.

Polling (Abfragen): System B fragt in regelmäßigen Abständen bei System A nach: „Gibt es etwas Neues?“ Meistens lautet die Antwort „nein“. Wenn doch, holt B die neuen Daten ab.

Webhook (Benachrichtigung): System A meldet sich von selbst, sobald etwas passiert. Dazu ruft es eine Internetadresse auf, die B vorher hinterlegt hat, und schickt die Daten des Ereignisses mit – fast immer als JSON in einer HTTP-POST-Anfrage.

Ein Alltagsvergleich: Polling ist, alle zehn Minuten zum Briefkasten zu gehen. Ein Webhook ist die Klingel des Paketboten.

	Polling	Webhook
Verzögerung	bis zum nächsten Abfrageintervall	Sekunden
Last auf beiden Systemen	dauerhaft, auch ohne Änderungen	nur bei Ereignissen
Erreichbarkeit nötig	nein, B fragt aktiv	ja, B muss aus dem Internet erreichbar sein
Verpasste Ereignisse	selten, der nächste Abruf holt nach	möglich, wenn B längere Zeit nicht erreichbar war
Einrichtung	API-Zugang genügt	Adresse beim Absender eintragen, Sicherheit beachten

Webhooks sind schneller und sparsamer. Polling ist robuster gegen Ausfälle des Empfängers. In der Praxis werden beide oft kombiniert: Webhooks für die Geschwindigkeit, ein gelegentlicher Abgleich per Polling als Sicherheitsnetz.

Wie ein Webhook aussieht

Ein vereinfachtes Beispiel, wie ein Shop eine bezahlte Bestellung meldet:

POST /webhook/bestellung-bezahlt HTTP/1.1
Host: automation.example.de
Content-Type: application/json
X-Signature: 3q2+7wJx…

{
  "event": "order.paid",
  "id": "evt_8f2c1a",
  "order": {
    "number": "1042",
    "email": "kunde@example.com",
    "total": "64.70",
    "currency": "EUR"
  }
}

Drei Bestandteile sind in fast jedem Webhook enthalten: die Art des Ereignisses, eine eindeutige ID und die eigentlichen Daten. Viele Anbieter schicken zusätzlich eine Signatur in einem Header mit.

Was der Empfänger richtig machen muss

Den Webhook einzurichten ist einfach: In n8n legen Sie einen Webhook-Node an, in Make das Modul „Custom webhook“, in Zapier „Webhooks by Zapier“. Die angezeigte Adresse tragen Sie beim Absender ein. Damit der Ablauf im Alltag zuverlässig läuft, braucht es vier weitere Dinge.

1. Prüfen, ob der Absender echt ist

Die Webhook-Adresse ist öffentlich erreichbar. Wer sie kennt, kann gefälschte Ereignisse schicken – etwa eine „bezahlte Bestellung“, die es nie gab. Seriöse Anbieter signieren deshalb jeden Webhook mit einem gemeinsamen Geheimnis (meist HMAC-SHA256). Der Empfänger berechnet die Signatur selbst und vergleicht.

Ein Beispiel in Node.js, sinngemäß so, wie es etwa Shopify verlangt:

import crypto from "node:crypto";

function istEcht(rohBody, signaturHeader, geheimnis) {
  const erwartet = crypto
    .createHmac("sha256", geheimnis)
    .update(rohBody)            // unveränderter Body als Buffer
    .digest("base64");
  const a = Buffer.from(erwartet);
  const b = Buffer.from(signaturHeader ?? "");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}

Zwei Details, an denen die Prüfung oft scheitert: Die Signatur muss über den unveränderten Rohtext berechnet werden, nicht über ein bereits geparstes und neu serialisiertes JSON. Und die Kodierung (Base64 oder Hex) unterscheidet sich je nach Anbieter. In n8n lässt sich der Rohtext über die Option „Raw Body“ des Webhook-Nodes abgreifen.

Bietet ein System keine Signatur an, sind ein schwer zu erratender Pfad und ein geheimer Header (in n8n über „Header Auth“) die Mindestabsicherung.

2. Schnell antworten

Der Absender wartet auf eine Antwort mit Status 2xx. Kommt sie nicht innerhalb weniger Sekunden, gilt die Zustellung als gescheitert. Daraus folgt: Erst den Empfang bestätigen, dann verarbeiten. In n8n ist das die Einstellung „Respond: Immediately“ am Webhook-Node. Wer mit der Antwort wartet, bis Rechnung, CRM-Eintrag und E-Mail erledigt sind, riskiert Zeitüberschreitungen und damit Wiederholungen.

3. Mit Wiederholungen rechnen

Scheitert eine Zustellung, versuchen es die meisten Anbieter erneut, oft mehrfach über Stunden. Das ist gut, denn ein kurzer Ausfall des Empfängers geht nicht verloren. Es bedeutet aber auch: Derselbe Webhook kann mehrfach ankommen, auch wenn er beim ersten Mal eigentlich verarbeitet wurde, die Antwort aber zu spät kam.

Manche Anbieter deaktivieren einen Webhook, der dauerhaft scheitert. Ein Blick in die Webhook-Einstellungen des Absenders gehört deshalb zu jeder Fehlersuche.

4. Doppelte Zustellungen unschädlich machen

Fachlich heißt das: Die Verarbeitung muss idempotent sein – ein zweites Mal ausgeführt, darf sie nichts Neues bewirken. Zwei bewährte Wege:

• Ereignis-ID merken: Bereits verarbeitete IDs in einer kleinen Tabelle speichern und Wiederholungen verwerfen.
• Im Zielsystem prüfen: Vor dem Anlegen einer Rechnung nachsehen, ob es zu dieser Bestellung schon eine gibt.

Wie das konkret für Shopify und Lexware Office aussieht, steht in Shopify-Bestellungen automatisch als Lexoffice-Rechnung anlegen.

Webhooks testen, ohne echte Daten zu erzeugen

Ein Webhook lässt sich schlecht testen, indem man auf das nächste echte Ereignis wartet. Besser sind diese drei Wege:

1. Testereignis des Absenders. Viele Systeme (Shopify, Stripe, HubSpot und andere) bieten in den Webhook-Einstellungen eine Schaltfläche, um ein Beispielereignis zu senden. Damit prüfen Sie Erreichbarkeit und Format.
2. Testmodus oder Testumgebung. Zahlungsanbieter haben einen Testmodus, Shops eine Entwicklungsumgebung oder Testbestellungen. So entstehen echte Ereignisse, ohne dass echtes Geld fließt.
3. Eigene Anfrage per Kommandozeile. Für den Empfänger allein genügt ein manueller Aufruf:

curl -X POST https://automation.example.de/webhook-test/bestellung-bezahlt \
  -H "Content-Type: application/json" \
  -d '{"event":"order.paid","id":"evt_test_1","order":{"number":"TEST-1"}}'

Mit dem dritten Weg lässt sich auch prüfen, ob die Doppelungssperre greift: dieselbe Anfrage zweimal senden und kontrollieren, dass nur ein Datensatz entsteht. Eine Anfrage ohne gültige Signatur muss abgewiesen werden – auch das gehört zum Test.

Häufige Fehler beim Einrichten

1. Test-URL statt Produktions-URL. n8n zeigt für jeden Webhook-Node zwei Adressen. Die Test-URL funktioniert nur, solange der Editor auf ein Testereignis wartet. Beim Absender gehört die Produktions-URL hinein, und der Workflow muss aktiv sein.
2. Lokale Adresse. localhost oder eine interne IP ist von außen nicht erreichbar. Bei selbst gehostetem n8n muss die öffentliche Adresse über die Umgebungsvariable WEBHOOK_URL gesetzt sein, sonst zeigt n8n falsche URLs an.
3. Zu viele Ereignisse abonniert. Wer „alle Änderungen an Kontakten“ abonniert, obwohl nur neue Kontakte interessieren, erzeugt unnötige Läufe und Kosten.
4. Personenbezogene Daten im Pfad. Parameter wie ?email=… landen in Server-Logs. Daten gehören in den Body.
5. Keine Überwachung. Wenn der Absender aufhört zu senden, passiert beim Empfänger nichts – auch kein Fehler. Mehr dazu in Fehlerbehandlung in n8n.

Checkliste für einen produktiven Webhook

• Produktions-URL beim Absender eingetragen, Workflow aktiv
• Nur die benötigten Ereignistypen abonniert
• Signatur oder geheimer Header wird geprüft
• Antwort sofort, Verarbeitung danach
• Doppelte Zustellungen führen nicht zu doppelten Datensätzen
• Fehler in der Verarbeitung werden gemeldet
• Gegenprobe für den Fall, dass gar keine Webhooks mehr ankommen
• Geheimnis im Zugangsdatenspeicher, nicht im Workflow

Webhooks in unseren Aufgaben

Viele Automatisierungen, die wir bauen, beginnen mit einem Webhook – bei Formularen, Bestellungen oder CRM-Änderungen. Signaturprüfung, sofortige Antwort und Schutz vor Doppelungen gehören dabei zu den Abnahmekriterien, nicht zu den Extras.

Häufige Fragen

Was ist der Unterschied zwischen Webhook und Polling?

Beim Polling fragt ein System in regelmäßigen Abständen nach, ob es etwas Neues gibt. Beim Webhook meldet sich das andere System von selbst, sobald etwas passiert, und schickt die Daten mit. Webhooks sind schneller und sparsamer, Polling ist robuster gegen Ausfälle des Empfängers; oft werden beide kombiniert.

Warum kommt derselbe Webhook mehrfach an?

Weil die meisten Anbieter eine Zustellung wiederholen, wenn nicht schnell eine Antwort mit Status 2xx kommt. Das passiert auch, wenn die Verarbeitung beim ersten Mal geklappt hat, die Antwort aber zu spät kam. Deshalb muss die Verarbeitung idempotent sein, etwa indem bereits verarbeitete Ereignis-IDs gespeichert und Wiederholungen verworfen werden.

Wie sichere ich eine Webhook-Adresse ab?

Prüfen Sie die Signatur, die viele Anbieter mitschicken, meist ein HMAC-SHA256 über den unveränderten Rohtext. Bietet ein System keine Signatur an, sind ein schwer zu erratender Pfad und ein geheimer Header die Mindestabsicherung. Das Geheimnis gehört in den Zugangsdatenspeicher des Tools, nicht in den Workflow.

---

Wenn Sie zwei Systeme in Echtzeit verbinden möchten, schreiben Sie das als Aufgabe auf Ihr Board: welches Ereignis, welches Ziel, was danach passieren soll. Sie laden uns in Ihr n8n, Make oder Zapier ein, nie per Passwort, und wir liefern den Workflow 48 Stunden nach Start deaktiviert, damit Sie den Zeitpunkt des Einschaltens bestimmen; die 48 Stunden zählen von Montag 8 Uhr bis Freitag 16 Uhr. Jede Lieferung prüft und gibt ein Senior-Entwickler frei, bevor sie zu Ihnen geht. Die erste Aufgabe ist kostenlos, weitere Verbindungen arbeiten wir im Prozess-Abo in Ihrer Reihenfolge ab. Typische Abläufe finden Sie im Leistungskatalog und unter Automatisierung; Fragen vorab klären wir gern in einem kostenlosen Projekt-Check.