Wenn ein Online-Shop eine Bestellung verarbeitet, muss diese Information in Sekunden an ERP, CRM, Versanddienst und Buchhaltung weitergereicht werden. Klassisches Polling fragt dafür in festen Intervallen nach Neuigkeiten und vergeudet dabei massiv Ressourcen: In einer Auswertung über 30 Millionen Anfragen fanden nur 1,5% der Polls tatsächlich ein Update, 98,5% waren vergeblich (Zapier). Eine Webhook-Architektur dreht das Prinzip um: Der Shop meldet ein Ereignis aktiv, sobald es eintritt. Dieser Event-Driven-Ansatz ist nicht nur effizienter, sondern auch echtzeitnah, vorausgesetzt, er ist sauber gebaut, mit Retries, Idempotenz, Signaturprüfung und Queues. Dieser Leitfaden zeigt, wie eine belastbare Webhook-Architektur für die Shop-Integration aussieht und wo die typischen Fallstricke lauern.
Webhooks vs. Polling: warum Event-Driven gewinnt
Polling und Webhooks lösen dasselbe Problem auf entgegengesetzte Weise. Beim Polling fragt das Zielsystem regelmäßig beim Shop nach: Gibt es etwas Neues? Beim Webhook ruft der Shop das Zielsystem aktiv auf, sobald ein Ereignis eintritt. Der Unterschied ist drastisch: Wer eine Schnittstelle alle 30 Sekunden abfragt, erzeugt 2.880 Anfragen pro Tag, selbst wenn nur zehn relevante Ereignisse eintreten, also 2.870 vergebliche Anfragen (Zapier). Ein Webhook sendet exakt zehn Aufrufe, einen pro Ereignis.
Diese Verschwendung hat reale Kosten. Polling erzeugt im Schnitt 66-mal mehr Serverlast als Webhooks (Zapier), und je kürzer das Intervall, desto stärker steigt die Last: Bei 10.000 Nutzenden und einem 5-Sekunden-Intervall können bis zu 10.000 Anfragen pro Sekunde anfallen, während Webhooks für dieselben Aktualisierungen nur etwa 150 Antworten pro Sekunde benötigen (Zapier). Hinzu kommt die Latenz: Polling liefert Daten erst beim nächsten Abfragezyklus, ein Webhook nahezu in Echtzeit.
| Kriterium | Polling | Webhooks (Event-Driven) |
|---|---|---|
| Auslösung | Festes Intervall | Bei Ereignis |
| Effizienz | 98,5% Anfragen vergeblich | Eine Anfrage pro Ereignis |
| Serverlast | Bis zu 66x höher | Niedrig, ereignisproportional |
| Latenz | Bis zum nächsten Zyklus | Nahezu Echtzeit |
| Komplexität | Einfach, aber teuer | Höher, aber skalierbar |
Das heisst nicht, dass Polling nicht sinnvoll ist. Für seltene Batch-Abgleiche oder Systeme ohne Webhook-Unterstützung bleibt es eine valide Option, ebenso als Fallback, wenn Ereignisse einmal verloren gehen. Für echtzeitnahe Shop-Prozesse wie Bestellübergabe, Bestandssynchronisation oder Versandstatus ist die Event-Driven-Architektur jedoch klar überlegen.
In der Praxis kombinieren robuste Integrationen beide Ansätze bewusst: Webhooks tragen die Last des Tagesgeschäfts und liefern Ereignisse nahezu in Echtzeit, während ein seltener, periodischer Abgleich als Sicherheitsnetz dient, um einen Datenstand zwischen Shop und Zielsystem zu verifizieren. So lassen sich die wenigen Ereignisse aufspüren, die trotz aller Vorkehrungen einmal durchrutschen, etwa wenn ein Empfänger über längere Zeit nicht erreichbar war und auch die Retries erschöpft sind. Dieser hybride Aufbau verbindet die Effizienz des Event-Driven-Modells mit der Vollständigkeitsgarantie eines Abgleichs, ohne die Nachteile reinen Pollings in Kauf zu nehmen.
Anatomie einer Webhook-Architektur
Eine produktionsreife Webhook-Architektur besteht aus mehr als einer URL, die Daten empfängt. Sie umfasst den Ereignisproduzenten (den Shop), den Transport (HTTP-POST mit Signatur), eine Eingangsschicht beim Empfänger, eine Queue zur Entkopplung, eine Retry-Mechanik und die eigentlichen Konsumenten wie ERP, CRM oder E-Mail-Versand. Erst dieses Zusammenspiel macht aus einem fragilen Aufruf eine belastbare Integration.
Producer (Shop)
Löst bei Ereignissen wie checkout.order.placed einen HTTP-POST aus. Shopware etwa bietet hierfür ein App- und Event-System für Business- und Lifecycle-Events (Shopware Docs).
Transport mit Signatur
Die Nutzlast wird als JSON über HTTPS gesendet und mit einer HMAC-Signatur versehen, damit der Empfänger Echtheit und Unversehrtheit prüfen kann.
Empfänger-Endpoint
Nimmt den POST an, validiert Signatur und Idempotenz-Key, antwortet schnell mit 2xx und legt das Ereignis in eine Queue, statt es synchron zu verarbeiten.
Queue und Consumer
Eine Message-Queue entkoppelt Empfang und Verarbeitung. Worker arbeiten Ereignisse ab, mit Retry bei Fehlern und Dead-Letter-Queue als letztem Auffangnetz.
Der entscheidende Architektur-Grundsatz lautet: schnell quittieren, asynchron verarbeiten. Der Endpoint sollte den Webhook entgegennehmen, minimal validieren und sofort mit einem 2xx-Status antworten. Die eigentliche Arbeit, also das Schreiben ins ERP oder das Aktualisieren des CRM, passiert danach asynchron aus der Queue. So bleibt der Endpoint auch bei Lastspitzen reaktionsschnell und der Producer erhält keine Timeouts, die unnötige Retries auslösen würden.
Idempotenz: das tragende Element
Praktisch alle Webhook-Anbieter liefern Ereignisse mindestens einmal (at-least-once), niemals genau einmal (Hookdeck). Das bedeutet: Früher oder später erhält Ihr Empfänger dasselbe Ereignis doppelt, etwa weil eine Quittung verloren ging und der Producer erneut sendet. Ohne Schutz führt das zu Doppelbuchungen, doppeltem Versand oder doppelten E-Mails. Idempotenz ist deshalb keine Kür, sondern die tragende Wand jeder produktiven Webhook-Integration (Hookdeck).
Das Prinzip ist einfach: Jedes Ereignis trägt eine eindeutige ID, die über alle Wiederholungen hinweg konstant bleibt. Der Empfänger speichert verarbeitete IDs und überspringt jede Wiederholung. So wird dieselbe Bestellung zugesichert nur einmal ins ERP geschrieben, egal wie oft der Webhook eintrifft. In der Praxis genügt dafür oft ein einfacher Speicher mit den verarbeiteten Ereignis-IDs und einem Ablaufdatum, etwa in einem schnellen Cache. Wichtig ist nur, dass die Prüfung und das Markieren als verarbeitet atomar erfolgen, damit zwei gleichzeitig eintreffende Kopien desselben Ereignisses nicht beide die Prüfung passieren.
public function handle(Request $request): Response
{
// 1. Signatur prüfen (HMAC, constant-time)
if (!$this->verifySignature($request)) {
return new Response('invalid signature', 401);
}
$eventId = $request->header('X-Event-Id');
// 2. Idempotenz: bereits verarbeitet?
if ($this->store->seen($eventId)) {
return new Response('ok', 200); // still mit 2xx quittieren
}
$this->store->markSeen($eventId);
// 3. In Queue legen, nicht synchron verarbeiten
$this->queue->push(new ProcessOrderEvent($request->getContent()));
// 4. Schnell quittieren
return new Response('accepted', 202);
}Die ID-Prüfung am Endpoint allein reicht nicht, wenn ein Worker mitten in der Verarbeitung abstürzt und das Ereignis erneut aus der Queue zieht. Auch die eigentliche Verarbeitung sollte idempotent sein, etwa durch upsert-Operationen statt blindem insert und durch eindeutige Schlüssel je Geschäftsvorfall.
Signaturprüfung und Sicherheit
Ein Webhook-Endpoint ist eine öffentlich erreichbare URL, die schreibende Aktionen auslöst. Ohne Authentifizierung könnte jeder gefälschte Ereignisse einschleusen. Der Standard zur Absicherung ist die HMAC-Signatur: Der Producer signiert die Nutzlast mit einem gemeinsamen Geheimnis, der Empfänger berechnet die Signatur neu und vergleicht sie. HMAC-SHA256 ist dabei das von den meisten modernen Anbietern genutzte Verfahren (Hooklistener). Shopware etwa signiert seine App-Webhooks mit einem SHA256-HMAC über dem Request-Body im Header shopware-shop-signature (Shopware Docs).
- Signatur über den Rohkörper berechnen, nicht über ein deserialisiertes und neu serialisiertes Objekt, da JSON die Reihenfolge der Felder verändern kann und der Hash sonst nicht passt (Hooklistener)
- Konstante Vergleichszeit verwenden (constant-time compare), um Timing-Angriffe auf die Signaturprüfung zu verhindern (Hooklistener)
- Zeitstempel mitsignieren und Ereignisse ablehnen, deren Zeitstempel zu weit zurückliegt, typischerweise mehr als fünf Minuten, um Replay-Angriffe zu unterbinden (Hooklistener)
- HTTPS erzwingen, damit Nutzlast und Signatur nicht im Klartext übertragen werden
- Secrets wie Passwörter behandeln: in Umgebungsvariablen oder einem Secret-Management ablegen, niemals im Code oder in der Versionsverwaltung (Hooklistener)
Eine gültige Signatur allein schützt nicht, wenn ein Angreifer ein abgefangenes, korrekt signiertes Ereignis erneut sendet. Etablierte Anbieter signieren deshalb die Kombination aus Zeitstempel und Nutzlast und verwerfen Ereignisse, deren Zeitstempel mehr als wenige Minuten abweicht (Hooklistener). So werden alte, wiederholte Signaturen automatisch ungültig.
Retries, Backoff und Dead-Letter-Queues
Netzwerke sind unzuverlässig, Zielsysteme haben Wartungsfenster, und Lastspitzen führen zu Timeouts. Ohne Wiederholungslogik gehen dabei Ereignisse verloren: Die Ausfallrate ohne Retry liegt bei 3-5% (Hookdeck). Was harmlos klingt, ist es nicht: Bei 100 Bestellungen am Tag bedeuten 3-5% bereits drei bis fünf verlorene Vorgänge, also fehlende ERP-Buchungen oder nicht versendete Bestätigungen (Hookdeck).
Die Lösung ist ein gestaffeltes Wiederholungsverfahren mit exponentiellem Backoff: Nach einem Fehlversuch wird mit wachsendem Abstand erneut zugestellt. Damit nicht tausende gleichzeitig fehlgeschlagene Ereignisse exakt zur selben Sekunde erneut anbranden (das sogenannte Thundering-Herd-Problem), wird zusätzlich Jitter eingestreut, also eine zufällige Streuung der Wartezeiten (Hookdeck).
- Erstzustellung sofort beim Eintreten des Ereignisses
- Retry mit Backoff bei vorübergehenden Fehlern (5xx, Timeout, 429), mit wachsenden Abständen plus Jitter
- Keine Retries bei dauerhaften Fehlern wie 4xx (ausser 429), da eine Wiederholung hier nichts ändert (Hookdeck)
- Dead-Letter-Queue (DLQ) als letztes Auffangnetz, wenn alle Versuche erschöpft sind, damit kein Ereignis still verschwindet (Hookdeck)
- Monitoring und Alerting auf die DLQ, damit fehlgeschlagene Ereignisse manuell nachverarbeitet werden können
Retries und Idempotenz greifen ineinander: Retries sorgen dafür, dass jedes Ereignis mindestens einmal ankommt, Idempotenz dafür, dass mehrfache Zustellung keinen Schaden anrichtet. Erst diese Kombination erreicht in der Praxis Zustellraten im hohen Neunziger-Prozentbereich, ohne Doppelverarbeitung zu riskieren.
Queues entkoppeln Empfang und Verarbeitung
Die Message-Queue ist das Herzstück einer skalierbaren Webhook-Architektur. Sie trennt das schnelle Annehmen eines Ereignisses vom potenziell langsamen Verarbeiten. Trifft ein Schwung Bestellungen gleichzeitig ein, etwa während einer Aktion, puffert die Queue die Last, und die Worker arbeiten sie in ihrem Tempo ab, ohne dass der Endpoint blockiert oder Ereignisse verloren gehen.
Dieser Entkopplungsgewinn ist messbar. Organisationen, die auf eine ereignisgesteuerte Architektur umstellen, berichten von 62% geringerer Systemlatenz, 58% höherem Durchsatz und 47% niedrigeren Infrastrukturkosten gegenüber synchronen Architekturen (IJSAT 2025). Entsprechend nutzen bereits 72% der Unternehmen ereignisgesteuerte Workflows für skalierbare, lose gekoppelte Systeme (Growin).
Lastspitzen abfangen
Die Queue puffert Bestellschübe, sodass keine Ereignisse bei Lastspitzen verloren gehen, ein bekannter Schwachpunkt bei direkter Verarbeitung.
Fehler isolieren
Fällt ein Zielsystem aus, stauen sich die Ereignisse in der Queue und werden nach der Wiederherstellung abgearbeitet, statt verloren zu gehen.
Unabhängig skalieren
Mehr Last bedeutet einfach mehr Worker. Empfang und Verarbeitung skalieren getrennt, was die Architektur elastisch macht.
Für Shop-Projekte heisst das konkret: Ein eintreffender Bestell-Webhook landet zunächst in der Queue. Von dort verteilen Worker das Ereignis an mehrere Konsumenten, etwa eine Versandschnittstelle, das ERP und den Bestätigungs-Mailversand. Jeder Konsument arbeitet unabhängig, mit eigener Retry-Logik. Fällt einer aus, laufen die anderen weiter. Genau diese Robustheit unterscheidet eine echte Integration von einem fragilen Punkt-zu-Punkt-Skript.
Auch die Nutzlast selbst verdient Aufmerksamkeit. Webhook-Payloads sollten nur die Daten enthalten, die der Empfänger zur Reaktion braucht, und bei größeren Datenmengen lohnt sich Kompression auf Transportebene, ähnlich wie bei der Brotli-Komprimierung von Shop-Assets. Schlanke, klar versionierte Payloads reduzieren nicht nur die übertragene Datenmenge, sondern erleichtern auch die Fehlersuche, weil jedes Ereignis nachvollziehbar bleibt. Ein verbreitetes Muster ist das sogenannte thin payload: Der Webhook enthält nur die Ereignis-ID und einen Verweis, und der Empfänger holt die vollständigen Daten bei Bedarf über die API nach. Das hält die Zustellung schnell und entkoppelt die Datenmenge von der Ereignisrate.
Ebenso wichtig ist die Beobachtbarkeit der gesamten Kette. Ohne Protokollierung jedes Zustellversuchs, jeder Signaturprüfung und jeder Queue-Bewegung bleibt eine Störung im Verborgenen, bis Kundinnen und Kunden sie melden. Eine durchdachte Architektur führt deshalb ein Ereignis-Logbuch, das für jedes Ereignis Status, Versuche und Endzustand festhält, und alarmiert automatisch, sobald die Dead-Letter-Queue wächst. So wird aus einer Black-Box ein nachvollziehbares System, in dem sich Fehlerursachen gezielt eingrenzen lassen, statt im Dunkeln zu tappen.
Was passiert, wenn die Architektur fehlt
Die Folgen mangelhafter Integration sind keine Theorie. Eine Erhebung zeigt, dass 60% der Händler im Vereinigten Königreich durch Schnittstellenausfälle direkte Umsatzverluste erlitten, etwa durch verzögerte Bestellungen oder Bestandsabweichungen (Uptrends, State of API Reliability 2025). Im selben Zeitraum sank die durchschnittliche API-Verfügbarkeit von 99,66% auf 99,46%, was 60% mehr Ausfallzeit im Jahresvergleich bedeutet (Uptrends).
Besonders kritisch wird es bei der Bestandsführung im Mehrkanalvertrieb: Fehlerhafte Synchronisation führt zu Überverkäufen und Marktplatzstrafen, und Rate-Limits werden bei Lastspitzen regelmäßig zum Bruchpunkt, mit fehlgeschlagenen Anfragen, verzögerten Zahlungen und Sync-Problemen als Folge (Uptrends). Eine ereignisgesteuerte Architektur mit Queue und Retry adressiert genau diese Schwachstellen, weil sie Lastspitzen puffert und verlorene Ereignisse automatisch nachholt, statt sie still fallen zu lassen.
Hier setzt eine durchdachte Middleware-Schicht an: Statt jedes System direkt mit jedem anderen zu verbinden, bündelt sie Ereignisse, vereinheitlicht Formate und sorgt für konsistente Retry- und Idempotenz-Regeln über alle Schnittstellen hinweg. Das gilt für Standardprozesse ebenso wie für komplexe Abläufe wie B2B-Bestellfreigaben oder den strukturierten EDI-Austausch, bei denen Ereignisse zuverlässig zwischen Shop, ERP und Geschäftspartnern fließen müssen.
Webhook-Architektur als Fundament zuverlässiger Integration
Eine Webhook-Architektur ist weit mehr als ein technisches Detail, sie entscheidet darüber, ob Bestellungen, Bestände und Kundendaten zuverlässig zwischen den Systemen fließen. Die Datenlage ist eindeutig: 98,5% vergeudete Polling-Anfragen (Zapier), 3-5% Ereignisverlust ohne Retry (Hookdeck) und 62% geringere Latenz mit ereignisgesteuerter Architektur (IJSAT 2025) zeigen, wie groß der Unterschied zwischen einem fragilen Skript und einer sauberen Architektur ist.
Die vier Bausteine greifen ineinander: Webhooks ersetzen verschwenderisches Polling, Queues entkoppeln und stabilisieren, Retries mit Backoff sichern die Zustellung, und Idempotenz plus Signaturprüfung machen die Verarbeitung sicher und wiederholungsfest. Erst zusammen ergeben sie eine Integration, die auch bei Lastspitzen und Teilausfällen verlässlich bleibt.
Als Agentur mit Schwerpunkt auf E-Commerce und Schnittstellen entwerfen und betreiben wir solche Architekturen für Online-Shops in Niedersachsen und darüber hinaus, von der ersten Event-Definition über Signatur- und Idempotenz-Logik bis zur Queue mit Monitoring. So wird aus einer Sammlung von Einzelschnittstellen ein belastbares, echtzeitnahes System, das mit Ihrem Shop mitwächst.
Dieser Artikel basiert auf Daten aus: Zapier (vergeudete Polling-Anfragen, Serverlast im Vergleich zu Webhooks), Hookdeck (Ausfallrate ohne Retry, At-least-once-Zustellung, Idempotenz, Backoff mit Jitter, Dead-Letter-Queues), Hooklistener (HMAC-Signaturprüfung, Rohkörper, constant-time compare, Zeitstempel gegen Replay-Angriffe, Secret-Management), Shopware Documentation (App- und Event-System, shopware-shop-signature HMAC), IJSAT 2025 (Latenz-, Durchsatz- und Kostenwirkung ereignisgesteuerter Architektur), Growin (Verbreitung ereignisgesteuerter Workflows) und Uptrends State of API Reliability 2025 (Umsatzverluste durch Schnittstellenausfälle, API-Verfügbarkeit, Rate-Limits). Die genannten Zahlen können je nach Branche, System und Umsetzung variieren.
Häufig gestellte Fragen zur Webhook-Architektur
Beim Polling fragt ein System in festen Intervallen aktiv nach Neuigkeiten, beim Webhook meldet die Quelle ein Ereignis selbstständig, sobald es eintritt. Polling ist einfach, aber ineffizient: In einer Auswertung waren rund 98,5% der Polling-Anfragen vergeblich (Zapier). Webhooks senden dagegen eine Anfrage pro Ereignis und liefern nahezu in Echtzeit.
Praktisch alle Anbieter liefern Ereignisse mindestens einmal, nicht zugesichert genau einmal (Hookdeck). Dadurch kann dasselbe Ereignis mehrfach eintreffen, etwa nach einem Retry. Ohne Idempotenz führt das zu Doppelbuchungen oder doppeltem Versand. Eine eindeutige Ereignis-ID, die beim Empfänger gespeichert wird, sorgt dafür, dass jedes Ereignis nur einmal verarbeitet wird.
Der Standard ist die Prüfung einer HMAC-Signatur, die der Sender mit einem gemeinsamen Geheimnis erzeugt und der Empfänger neu berechnet (Hooklistener). Ergänzend gehören HTTPS, ein zeitlich begrenzter Zeitstempel gegen Replay-Angriffe und ein konstanter Vergleich gegen Timing-Angriffe dazu. Shopware nutzt dafür beispielsweise den Header shopware-shop-signature (Shopware Docs).
Eine belastbare Architektur wiederholt die Zustellung mit exponentiellem Backoff und Jitter. Schlägt sie nach allen Versuchen fehl, wandert das Ereignis in eine Dead-Letter-Queue zur manuellen Nachverarbeitung (Hookdeck). Ohne diese Mechanik gehen erfahrungsgemäß 3-5% der Ereignisse verloren (Hookdeck).
Die Queue entkoppelt den schnellen Empfang vom langsameren Verarbeiten. Der Endpoint quittiert sofort und legt das Ereignis in die Queue, Worker arbeiten es danach asynchron ab. Das fängt Lastspitzen ab, isoliert Fehler und erlaubt unabhängiges Skalieren. Unternehmen berichten mit ereignisgesteuerter Architektur typischerweise von deutlich geringerer Latenz und höherem Durchsatz (IJSAT 2025).
In der Regel ja, sobald mehrere Systeme zuverlässig zusammenspielen müssen. Schon bei wenigen Bestellungen pro Tag verhindert eine saubere Architektur stille Datenverluste, die im Mehrkanalvertrieb zu Überverkäufen führen können (Uptrends). Der Aufwand lässt sich skalieren: Auch eine schlanke Lösung mit Signaturprüfung, Idempotenz und einfacher Retry-Logik bringt bereits einen großen Zuverlässigkeitsgewinn.