Webhooks — wenn Programme sich gegenseitig Bescheid sagen.

Das Prinzip.

Stell dir vor, du wartest auf ein Paket. Du kannst alle zehn Minuten zur Tür gehen und nachsehen — oder der Bote klingelt. Ein Webhook ist die Klingel.

Technisch: Programm A bekommt eine Adresse von Programm B. Wenn bei A ein bestimmtes Ereignis eintritt, schickt A eine Nachricht mit den Daten an diese Adresse. B empfängt sie und startet einen Ablauf.

Programm A muss dafür Webhooks unterstützen — viele Shopsysteme, Formular-Erweiterungen, Zahlungsanbieter, CRM- und Buchhaltungsprogramme tun das. Programm B braucht eine erreichbare Adresse — genau das stellen Werkzeuge wie n8n und Make bereit (n8n).

Webhook oder regelmäßige Abfrage.

Die Kostenzeile ist praktisch relevant: Bei Make etwa verbrauchen Auslöser, die regelmäßig nachsehen, auch dann Credits, wenn es nichts Neues gibt (Kosten). Wo Webhooks verfügbar sind, sind sie fast immer die bessere Wahl.

Die letzte Zeile ist der Vorteil der Abfrage: Sie holt nach, was während eines Ausfalls passiert ist. Für kritische Abläufe kann eine Kombination sinnvoll sein — Webhook für die Geschwindigkeit, gelegentliche Abfrage als Abgleich.

Was übertragen wird.

Ein Webhook schickt eine Anfrage an die Adresse, meist mit den Daten im JSON-Format — einer strukturierten Textform, die Programme leicht lesen können. Bei einer Bestellung etwa: Bestellnummer, Kunde, Positionen, Beträge, Zahlungsart.

Manche Dienste schicken alle Daten mit, andere nur eine Kennung und einen Hinweis, dass sich etwas geändert hat. Dann holt der Empfänger die Details anschließend über die Schnittstelle ab. Das ist sicherer, weil sensible Daten nicht in der Meldung selbst stehen.

Die Antwort.

Der Empfänger bestätigt den Erhalt mit einem Statuscode. Ein Erfolgscode heißt: angekommen. Ein Fehlercode oder keine Antwort heißt für den Sender: nicht angekommen.

Wichtig: Viele Sender warten nur kurz auf die Antwort. Wenn der Empfänger erst den ganzen Ablauf abarbeitet und dann antwortet, kann die Zeit überschritten werden — der Sender hält die Meldung für gescheitert und schickt sie erneut. Besser: sofort bestätigen, dann verarbeiten.

Absichern.

Eine Webhook-Adresse ist im Prinzip öffentlich erreichbar. Wer sie kennt, kann Daten schicken — auch gefälschte. Bei einem Ablauf, der aus einer Meldung eine Rechnung oder einen Versand auslöst, ist das ein echtes Risiko.

• Lange, zufällige Adresse, nicht erratbar.
• Signaturprüfung: Viele Sender signieren ihre Meldungen mit einem geheimen Schlüssel. Der Empfänger prüft die Signatur und verwirft alles andere.
• Geheimer Kopfeintrag oder Anmeldung, wenn der Sender keine Signatur kann.
• Nur verschlüsselte Verbindungen.
• Daten prüfen, bevor gehandelt wird — passt die Bestellnummer, existiert der Kunde?

Wenn der Empfänger nicht da ist.

Was passiert, wenn n8n gerade aktualisiert wird oder der Server neu startet, während eine Meldung kommt? Das hängt vom Sender ab.

Gute Sender wiederholen fehlgeschlagene Meldungen mehrmals mit wachsenden Abständen. Andere versuchen es einmal und geben auf. Manche schalten den Webhook nach mehreren Fehlschlägen sogar ab — WooCommerce etwa deaktiviert Webhooks nach wiederholten Fehlern.

Deshalb gehört zu jedem wichtigen Webhook die Frage: Wie verhält sich der Sender bei Ausfall? Und gibt es einen Abgleich, der Verpasstes nachholt (Fehler überwachen)?

Doppelte Meldungen.

Die Kehrseite der Wiederholung: Manchmal kommt eine Meldung doppelt — etwa wenn die Bestätigung zu spät kam. Ein Ablauf, der bei jeder Meldung eine Rechnung erzeugt, erzeugt dann zwei.

Die Lösung heißt Idempotenz: Der Ablauf prüft, ob er diese Meldung schon verarbeitet hat — etwa anhand der Bestellnummer — und tut beim zweiten Mal nichts. Das gehört in jeden Ablauf, der etwas mit Folgen auslöst (Doppelte Bestellungen).

Webhooks testen.

1. Testadresse im Werkzeug verwenden und ein echtes Ereignis auslösen.
2. Empfangene Daten ansehen: Welche Felder kommen, in welchem Format?
3. Ablauf mit diesen Daten bauen.
4. Produktivadresse eintragen, Ablauf aktivieren.
5. Erneut auslösen und prüfen, ob alles ankommt.
6. Fehlerfall testen: Was passiert bei fehlenden Feldern?

Schritt vier ist die häufigste Fehlerquelle: Die Testadresse funktioniert nur im Testmodus. Im Betrieb kommen dort keine Meldungen an (WordPress mit n8n).

Beispiele aus der Praxis.

• Formular abgesendet → Anfrage ins CRM (Formular ins CRM).
• Bestellung eingegangen → Rechnung und Versand.
• Zahlung bestätigt → Bestellstatus setzen, Zugang freischalten.
• Termin gebucht → Kalender, CRM, Erinnerung.
• Dokument unterschrieben → Ablage, Auftrag anlegen.

Wenn du nicht weiterkommst.

Wenn du Webhooks einrichten willst und sicher sein möchtest, dass sie zuverlässig und abgesichert laufen. Ich prüfe den Ablauf, baue ihn sauber auf und erkläre dir, was er tut. Die Übersicht aller Themen findest du unter Prozessautomatisierung, für Abläufe mit KI-Anteil unter KI-Automatisierung.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Prozessautomatisierung und Schnittstellen sind ein Kern meiner Arbeit — ich baue Abläufe mit n8n, Make und eigenem Code, verbinde Websites, Shops, CRM- und Buchhaltungssysteme und unterrichte das Thema als Dozent. Meinen eigenen Betrieb lasse ich mit genau diesen Werkzeugen laufen.

Der Unterschied zu einem reinen Werkzeug-Einrichter: Ich verstehe die Systeme an beiden Enden der Verbindung. Wenn ein Ablauf scheitert, liegt es selten an der Automatisierung, sondern an einer Schnittstelle, einem Datenformat oder einer Annahme über den Prozess. Genau dort setze ich an.

Was du bekommst: eine ehrliche Einschätzung, was sich lohnt, einen Ablauf, der auch dann noch läuft, wenn etwas Unerwartetes passiert, und eine Dokumentation, mit der du ihn verstehst — auch wenn die Antwort lautet, dass sich etwas nicht zu automatisieren lohnt.