Webhooks erklärt: Echtzeit-Daten zwischen deinen Systemen

Wenn dein Shop eine Bestellung bekommt und das ERP es zwei Stunden später erfährt, hast du ein Problem. Wenn dein CRM erst beim nächsten Sync von der Mail-Adress-Änderung des Kunden weiß, hast du ein anderes. Webhooks sind der unscheinbare Mechanismus, der hinter den meisten modernen Integrationen steckt, und sie sind erstaunlich oft falsch implementiert.

Wer einmal verstanden hat, wie Webhooks funktionieren und wo die typischen Fallen liegen, baut robustere Systeme und spart sich endlose Debugging-Sessions, wenn Daten zwischen Shop, ERP und CRM nicht zusammenpassen.

Was ein Webhook eigentlich ist

Ein Webhook ist eine Benachrichtigung, die ein System automatisch an eine vorher definierte URL sendet, sobald ein bestimmtes Ereignis eintritt. Der entscheidende Unterschied zur klassischen API: Du fragst nicht nach. Das System meldet sich, wenn etwas passiert.

Manche Entwickler nennen Webhooks „Reverse APIs”, weil die Datenrichtung sich umdreht. Bei einer normalen API stellt deine Anwendung eine Anfrage und erhält eine Antwort. Beim Webhook macht das andere System die Anfrage an deinen Server, sobald ein Event passiert. Push statt Pull.

Ein einfaches Beispiel: Ein Kunde bestellt im Shopware-Shop. Shopware sendet daraufhin einen HTTP-POST-Request an eine URL deines ERP-Systems, mit allen relevanten Bestelldaten im Body. Das ERP empfängt die Daten, legt einen Auftrag an, fertig. Sekunden statt Stunden.

Webhook vs. Polling: warum der Unterschied teuer ist

Vor Webhooks war Polling die übliche Methode. Dein System fragt regelmäßig beim anderen System nach: „Gibt es was Neues?” Alle fünf Minuten, alle 30 Sekunden, je nach Frust und Server-Last.

Das Problem ist offensichtlich, sobald man sich die Zahlen anschaut. Zapier hat einmal geschätzt, dass nur etwa 1,5 Prozent aller Polling-Anfragen tatsächlich neue Daten zurückbringen. Die restlichen 98,5 Prozent sind verschwendete Ressourcen. Server-Last, Bandbreite, API-Limits, alles für nichts.

Webhooks drehen das Verhältnis um. Es passiert genau dann etwas, wenn es etwas zu tun gibt. AWS SNS schafft beispielsweise typische Liefer-Latenzen unter 30 Millisekunden. Für die meisten Geschäftsanwendungen ist das nahezu Echtzeit.

Trotzdem ist Polling nicht tot. Wenn dein Quellsystem keine Webhooks anbietet, hast du keine Wahl. Wenn deine Endpunkte regelmäßig nicht erreichbar sind oder Events sich häufig ändern und du nur den letzten Zustand brauchst, kann Polling sogar einfacher sein. Aber als Standard-Architektur für moderne Integrationen ist es überholt.

Wo Webhooks im Mittelstand wirklich Sinn ergeben

In Projekten sehen wir vor allem vier Bereiche, in denen Webhooks den Aufwand sofort spürbar reduzieren.

Bestell- und Auftragsabwicklung im E-Commerce. Shopware, Shopify, WooCommerce, alle drei senden bei Bestellung, Stornierung, Versand oder Rückerstattung Webhooks. Wer das ERP per Webhook anbindet, hat keine Synchronisierungslücken mehr.

Buchhaltung und Rechnungswesen. Tools wie Stripe oder Paypal melden Zahlungseingänge per Webhook. Das Buchhaltungssystem kann den Zahlungseingang sofort verbuchen, ohne dass jemand am Monatsende manuell abgleicht.

CRM-Synchronisierung. Wenn jemand das Kontaktformular auf der Website ausfüllt, kann ein Webhook den Lead direkt im CRM anlegen, einen Slack-Channel benachrichtigen und eine erste E-Mail anstoßen. Alles in einem Schritt, ohne Verzögerung.

Workflow-Automation. Tools wie Make, n8n oder Zapier basieren in Wahrheit zum großen Teil auf Webhooks. Sie sind die Klebestelle zwischen Systemen, die ursprünglich nicht miteinander reden sollten.

Drei Themen, die fast jedes Webhook-Projekt aus der Bahn werfen

Hier wird es technisch, aber wer das überspringt, baut sich Probleme ein, die später schwer zu finden sind.

Sicherheit: Signaturen sind nicht optional

Eine Webhook-URL ist im Internet erreichbar. Wenn jemand sie kennt, kann er beliebige Requests an dein System schicken. Wenn dein Endpoint blind alles akzeptiert, was reinkommt, ist das eine Sicherheitslücke mit Ansage.

Der Standard-Schutz heißt HMAC-Signaturverifikation. Stripe, Shopify, GitHub und praktisch alle anderen großen Anbieter signieren ihre Webhooks mit SHA-256 und einem geheimen Schlüssel. Im Header steht etwas wie X-Shopify-Hmac-Sha256 oder Stripe-Signature. Dein Server muss den Body der Anfrage mit dem gleichen Schlüssel hashen und das Ergebnis vergleichen.

Zwei häufige Fehler dabei: Erstens, mit == vergleichen statt mit einer zeitkonstanten Funktion wie crypto.timingSafeEqual() in Node.js oder hmac.compare_digest() in Python. Das öffnet Timing-Angriffe. Zweitens, den Body parsen, bevor man die Signatur prüft. Die Signatur muss auf dem rohen Body berechnet werden, sonst stimmt der Hash nie.

Bei Stripe kommt zusätzlich ein Zeitstempel mit, sodass alte abgefangene Requests nicht beliebig wiedergespielt werden können. Standardmäßig akzeptiert das SDK eine Toleranz von 5 Minuten.

Idempotenz: derselbe Webhook kommt zweimal

Webhooks dürfen mehrfach ankommen. Shopify dokumentiert das offen: Derselbe Webhook kann mehr als einmal gesendet werden. Wenn dein System bei einer Bestellung jedes Mal einen neuen Auftrag im ERP anlegt, hast du am Wochenende plötzlich 14 identische Aufträge.

Die Lösung ist Idempotenz. Jeder Webhook hat eine eindeutige ID, bei Shopify zum Beispiel X-Shopify-Webhook-Id. Dein System speichert die ID in einem Cache oder einer Datenbank-Tabelle, üblicherweise mit einer Lebensdauer zwischen 7 und 30 Tagen. Bevor verarbeitet wird, prüfst du, ob die ID schon bekannt ist. Wenn ja, bestätigst du den Empfang und machst sonst nichts.

Das klingt trivial, wird in der Praxis aber regelmäßig vergessen, vor allem in selbstgebauten Integrationen.

Retries: was passiert, wenn dein Server kurz down ist

Webhook-Anbieter senden bei Fehlern erneut. Stripe versucht es mehrere Tage lang, Shopify in mehreren Wellen. Das ist ein Feature, kein Bug. Aber dein Server muss damit umgehen können.

Die Best Practice: Bestätige den Empfang sofort mit einem 2xx-HTTP-Status, dann verarbeite asynchron. Wer im Webhook-Handler 30 Sekunden lang Daten ins ERP schreibt und der Anbieter wegen Timeout abbricht, baut eine Endlosschleife aus Retries. Sinnvoll ist eine Queue (Redis, SQS, RabbitMQ), in die der Webhook gleich abgelegt wird, ein Worker arbeitet sie ab.

Für deine eigene Implementierung Richtung Drittsystem gilt: exponentielles Backoff mit Jitter. Erste Wiederholung nach 1 Sekunde, dann 2, 4, 8, 16, mit kleinen zufälligen Verzögerungen, damit nicht alle gleichzeitig zurückkommen. Nach 5 bis 10 Versuchen ab in eine Dead-Letter-Queue zur manuellen Prüfung.

Was du in der Praxis brauchst, bevor es losgeht

Bevor du in einem Projekt das erste webhook_url-Feld einträgst, sollten drei Punkte stehen:

Eine HTTPS-erreichbare URL. Webhooks senden sensible Daten. HTTP ist 2026 keine Option. Ein gültiges TLS-Zertifikat ist Pflicht, viele Anbieter (Shopify zum Beispiel) lehnen unsichere Endpunkte ab.

Logging und Monitoring. Wenn ein Webhook nicht ankommt, willst du das wissen, bevor der Kunde anruft. Mindestens jede eingehende Anfrage mit Zeitstempel, Quell-IP, Status und Verarbeitungsdauer loggen. Tools wie Hookdeck, Svix oder ein einfacher selbstgebauter Proxy helfen, wenn das Volumen wächst.

Saubere Idempotenz von Anfang an. Nachträglich einbauen ist schmerzhaft, weil dann alle bisherigen Datensätze ungeprüft sind.

Webhooks sind kein exotisches Tech-Feature, sondern das Rückgrat moderner Geschäftsprozesse. Wer sie ernst nimmt, baut Systeme, die zusammenpassen. Wer sie als Wegwerf-Trigger behandelt, hat mit Schnittstellen-Stress zu kämpfen, der eigentlich gar nicht sein müsste.

Wenn du bei einer Systemintegration oder Automatisierung gerade vor genau dieser Architekturfrage stehst und unsicher bist, ob ihr das selbst sauber baut: In einer Fokus-Session klären wir die wichtigsten Architekturpunkte und wo individuelle Softwareentwicklung den Unterschied macht.