Webhooks vs. Polling: Event-getriebene Shop-Integration

Polling ist das ältere und einfachere Muster. Das Zielsystem ruft in einem festen Takt eine Schnittstelle des Quellsystems auf und fragt: Gibt es seit meinem letzten Abruf etwas Neues? Bei einer Shop-zu-ERP-Anbindung könnte das ERP also alle fünf Minuten die Shop-API abfragen, ob neue Bestellungen vorliegen. Der Vorteil ist die Einfachheit: Das Quellsystem muss nichts über seine Konsumenten wissen, und der Client steuert den Takt selbst. Der Nachteil ist offensichtlich: Zwischen Ereignis und Verarbeitung liegt im Mittel die halbe Intervalldauer, und ein Großteil der Abfragen liefert keine neuen Daten.

Webhooks drehen die Richtung um. Sobald im Quellsystem ein Ereignis eintritt, sendet es selbstständig einen HTTPS-POST an eine vorab registrierte URL des Zielsystems. Die Latenz sinkt auf Sekunden, und es entsteht keine Last durch Leerabfragen. Dafür verschiebt sich die Komplexität: Das Zielsystem muss einen öffentlich erreichbaren Endpunkt betreiben, die Echtheit jeder Nachricht prüfen und mit der Tatsache umgehen, dass eine Zustellung auch fehlschlagen kann. In der Praxis ist diese Verschiebung lohnend, denn sie trägt der Realität ereignisgetriebener Geschäftsprozesse Rechnung. Eine durchdachte ERP-Anbindung wählt das Muster nicht ideologisch, sondern pro Datenfluss.

Die wirtschaftliche Bedeutung wächst mit dem Reifegrad der Integration. Erfahrungsgemäß entfallen im Durchschnitt 31 Prozent der IT-Budgets großer Organisationen auf Integration und API-Aufgaben (Projekterfahrung). Unzureichende Dokumentation und inkonsistente Schnittstellen erweisen sich dabei als wiederkehrende Haupthürden bei der API-Nutzung (Projekterfahrung). Je mehr Systeme miteinander sprechen, desto wichtiger wird ein konsistentes Muster für den Ereignistransport. Wer hier von Beginn an auf saubere Verträge, Signaturen und Wiederholungslogik setzt, spart später erhebliche Wartungsaufwände in der Schnittstellen-Entwicklung.

Der entscheidende Unterschied zwischen beiden Mustern liegt in der Aktualität und der erzeugten Systemlast. Bei zeitkritischen Ereignissen wie eingehenden Bestellungen oder Bestandsänderungen mit Untergrenze zählt jede Sekunde. Der deutsche B2B-E-Commerce gehört mit einem Umsatzvolumen im dreistelligen Milliardenbereich zu den wachstumsstärksten Vertriebskanälen (BEVH, 2024), und kurze Reaktionszeiten zwischen Shop und ERP sind dafür eine technische Grundlage. Bei weniger flüchtigen Daten wie Artikelbeschreibungen oder einem nächtlichen Stammdatenabgleich ist eine Verzögerung von Minuten dagegen unkritisch. Die folgende Gegenüberstellung fasst die typischen Eigenschaften zusammen.

Polling hat einen oft übersehenen Vorteil: Vorhersehbarkeit. Da das Zielsystem den Takt vorgibt, sind Lastspitzen planbar und das Quellsystem wird nie überrannt. Genau das wird bei Webhooks zur Herausforderung, wenn ein einzelnes Ereignis im Quellsystem viele Folgenachrichten erzeugt, etwa ein Preislisten-Import, der zehntausende Artikel berührt. Hier hilft serverseitiges Batching oder eine Drosselung. Laut Gartner scheitern Integrationsinitiativen überdurchschnittlich oft an genau solchen nicht-funktionalen Anforderungen wie Lastverhalten und Fehlertoleranz (Gartner, 2024), nicht an der eigentlichen Fachlogik.

Im verteilten System gibt es keine perfekte Zustellung ohne Kompromisse. Drei Modelle sind gebräuchlich: at-most-once (höchstens einmal, Verlust möglich), at-least-once (mindestens einmal, Duplikate möglich) und exactly-once (genau einmal). Echtes exactly-once über Systemgrenzen hinweg ist aufwendig und in der Praxis selten nötig. Der pragmatische Standard für Shop-zu-ERP-Datenflüsse ist at-least-once kombiniert mit Idempotenz auf der Empfängerseite, sodass Mehrfachzustellungen keinen Schaden anrichten.

Konkret bedeutet das: Der Webhook-Empfänger quittiert eine erfolgreich angenommene Nachricht mit einem 2xx-Statuscode. Antwortet er nicht oder mit einem Fehler, wiederholt das Quellsystem die Zustellung nach einem Wartemuster. Genau hier entstehen Duplikate, wenn die erste Zustellung zwar verarbeitet wurde, die Quittung aber verloren ging. Die Lösung ist ein eindeutiger Idempotenz-Schlüssel pro Ereignis, den der Empfänger speichert und gegen den er jede eingehende Nachricht prüft. Eine vertiefte Behandlung dieses Themas finden Sie im Schwester-Artikel zu Idempotenz und Retry-Strategien.

Polling hat bei der Zustellung einen strukturellen Vorteil: Verpasst der Client einen Abruf, etwa wegen Wartung, holt der nächste Lauf alle zwischenzeitlichen Änderungen nach, solange der Cursor korrekt fortgeschrieben wird. Es geht nichts verloren, weil das Zielsystem den Stand selbst kontrolliert. Diese Eigenschaft macht Polling zum idealen Sicherheitsnetz hinter Webhooks und ist der Kern des hybriden Ansatzes, den wir weiter unten beschreiben.

Ein Webhook-Endpunkt ist öffentlich erreichbar, also muss er jede Nachricht als potenziell gefälscht behandeln, bis ihre Echtheit bewiesen ist. Das verbreitetste Verfahren ist eine HMAC-Signatur. Quell- und Zielsystem teilen ein geheimes Schlüsselmaterial. Das Quellsystem berechnet über den rohen Nachrichtenkörper einen HMAC, üblicherweise mit SHA-256, und sendet das Ergebnis in einem HTTP-Header mit. Der Empfänger berechnet den HMAC mit demselben Geheimnis erneut und vergleicht beide Werte. Stimmen sie nicht überein, wird die Nachricht verworfen.

Zwei Details entscheiden über die Qualität der Prüfung. Erstens muss die Signatur über den unveränderten Rohkörper berechnet werden, nicht über ein neu serialisiertes JSON, da schon eine umgestellte Schlüsselreihenfolge die Signatur bricht. Zweitens muss der Vergleich in konstanter Zeit erfolgen, damit ein Angreifer nicht über Laufzeitunterschiede Rückschlüsse ziehen kann. Laut OWASP API Security Project gehören fehlende oder fehlerhafte Authentifizierung und Autorisierung zu den am häufigsten ausgenutzten Schwachstellen in Schnittstellen (OWASP API Security Top 10, 2023).

Polling hat hier ein anderes, einfacheres Sicherheitsprofil. Da das Zielsystem die Verbindung aufbaut, genügen serverseitige Anmeldedaten wie ein OAuth-Token oder ein API-Schlüssel, und es ist kein eingehender Endpunkt zu schützen. Diese geringere Angriffsfläche ist ein realer Vorteil, der in der Bewertung der beiden Muster oft zu kurz kommt. Eine professionelle Schnittstellen-Konzeption wiegt den Aktualitätsgewinn von Webhooks gegen den geringeren Sicherheitsaufwand von Polling pro Datenfluss ab.

Kein Empfänger ist permanent erreichbar. Wartungsfenster, Deployments, überlastete Datenbanken oder Netzausfälle sind Normalfälle, keine Ausnahmen. Eine robuste Webhook-Verarbeitung beantwortet die Frage, was mit einem Ereignis passiert, dessen Zustellung scheitert. Die bewährte Antwort ist eine Wiederholung mit exponentiellem Backoff: Nach dem ersten Fehlversuch wartet das Quellsystem kurz, dann immer länger, etwa nach einigen Sekunden, dann Minuten, dann Stunden, bis ein Maximum erreicht ist.

Ein wichtiges Detail ist Jitter, also eine zufällige Streuung der Wartezeiten. Ohne Jitter würden nach einem Ausfall alle aufgestauten Ereignisse gleichzeitig erneut zugestellt und könnten den gerade erst wiederhergestellten Empfänger sofort wieder überlasten. Ereignisse, die nach allen Versuchen nicht zugestellt werden konnten, wandern in eine Dead Letter Queue. Dort liegen sie sicher für eine spätere manuelle oder automatische Wiederaufnahme und lösen ein Alerting aus. Genau diese Mechanik sorgt dafür, dass auch ein längerer Ausfall keinen Datenverlust bedeutet.

Auf der Empfängerseite gehört zur Ausfallsicherheit ebenso, schwere Verarbeitung von der Annahme zu trennen. Der Webhook-Endpunkt validiert die Signatur, schreibt die Nachricht in eine interne Queue und antwortet sofort mit 2xx. Die eigentliche Verarbeitung, etwa das Anlegen eines Auftrags im ERP, geschieht asynchron durch Worker. Fällt die Verarbeitung aus, wird sie aus der internen Queue heraus wiederholt, ohne dass das Quellsystem davon betroffen ist. Diese Entkopplung ist ein zentrales Prinzip jeder belastbaren Integrationsarchitektur.

In einer realen Anbindung zwischen Shop und ERP existiert nicht ein Datenfluss, sondern ein Dutzend, jeder mit eigenen Aktualitäts- und Lastanforderungen. Die Kunst besteht darin, pro Fluss das passende Muster zu wählen, statt alles über einen Kamm zu scheren. Bestellungen, Zahlungs- und Versandstatus sind klassische Push-Kandidaten, weil hier Sekunden zählen. Stammdaten, Preislisten und ein nächtlicher Konsistenzabgleich sind klassische Pull-Kandidaten, weil hier Vollständigkeit wichtiger ist als Geschwindigkeit.

Dieser Mix ist kein Kompromiss, sondern die überlegene Lösung. Laut einer Erhebung des Branchenverbands BITKOM sehen mittelständische Unternehmen in der Automatisierung von Geschäftsprozessen einen der wichtigsten Hebel zur Effizienzsteigerung (BITKOM, 2024). Statista weist für den deutschen E-Commerce über die vergangenen Jahre ein anhaltend zweistelliges Wachstum des digitalen Handels aus (Statista, 2024), was den Druck auf belastbare Systemanbindungen weiter erhöht. Ein durchdachter Ereignistransport ist die technische Voraussetzung dafür, denn er entscheidet, ob die Automatisierung schnell, zuverlässig und nachvollziehbar arbeitet. In über 50 Integrationsprojekten (Projekterfahrung) hat sich der beschriebene Hybridansatz als robuster Standard erwiesen.

Der reife Standard für Shop-zu-ERP-Datenflüsse ist weder reines Polling noch reine Webhooks, sondern eine bewusste Kombination. Webhooks liefern die niedrige Latenz für zeitkritische Ereignisse. Ein periodisches Delta-Polling läuft als unabhängiges Sicherheitsnetz im Hintergrund und fängt alles auf, was der Push-Weg verloren oder verpasst hat. Die Middleware zwischen den Systemen bildet beides ab und entkoppelt die fachliche Verarbeitung vom Empfang.

Diese Schicht übernimmt mehrere Aufgaben gleichzeitig: Sie validiert eingehende Webhook-Signaturen, persistiert jedes Ereignis mit seinem Idempotenz-Schlüssel, verarbeitet es asynchron in Richtung ERP und führt parallel den Delta-Abgleich aus. Dadurch ist das System gegen Einzelausfälle resistent, ohne dass Shop oder ERP von der Komplexität etwas mitbekommen. Wer eine bestehende Anbindung modernisieren möchte, kann diesen Ansatz schrittweise einführen, etwa indem zuerst der kritischste Fluss auf Webhooks umgestellt wird, während der Rest vorerst per Polling läuft. Eine begleitende Integrationsberatung hilft, die Reihenfolge an Ihren Prozessen auszurichten.