Webhook
Ein Webhook ist eine automatische Benachrichtigung, die ein System bei einem bestimmten Ereignis von sich aus per HTTP an eine hinterlegte Adde eines Zielsystems schickt. Statt aktiv nachzufragen, wird das Zielsystem sofort informiert – im ERP-Umfeld etwa über neue Bestellungen, Zahlungen oder Bestandsänderungen.
Ein Webhook ist ein automatischer Rückruf zwischen zwei Software-Systemen: Sobald in einem Quellsystem ein festgelegtes Ereignis eintritt – zum Beispiel eine neue Bestellung, eine erfolgreiche Zahlung oder eine geänderte Lieferadresse –, schickt dieses System von sich aus eine kleine Nachricht per HTTP an eine vorher hinterlegte Web-Adresse (die „Callback-URL“) eines anderen Systems. Das Zielsystem, etwa ein ERP, erfährt so unmittelbar von dem Ereignis, ohne selbst nachfragen zu müssen. Der Name spielt auf einen „Haken“ (Hook) an, den man in fremden Code einhängt, um bei bestimmten Ereignissen benachrichtigt zu werden.
Der entscheidende Unterschied zu einer klassischen Abfrage liegt in der Richtung: Bei einem Webhook wird das Zielsystem informiert (Push), statt in kurzen Abständen selbst anzuklopfen (Pull). Deshalb gilt der Webhook als die effizienteste Art, Ereignisse nahezu in Echtzeit weiterzugeben. Im ERP- und E-Commerce-Umfeld sind Webhooks der Standardweg, damit Shop, Marktplatz, Payment-Dienstleister und Versanddienst dem Warenwirtschaftssystem sofort melden, wenn etwas Relevantes passiert.
Auf einen Blick
- Webhook = automatische Push-Benachrichtigung bei einem Ereignis, gesendet per HTTP an eine Callback-URL
- Grundprinzip „don’t call us, we’ll call you“: Das Quellsystem meldet sich, das Zielsystem wartet
- Liefert Ereignisse nahezu in Echtzeit – ideal für Bestellungen, Zahlungen, Bestandsänderungen
- Spart im Vergleich zum Polling Rechenlast und Datenverkehr
- Absicherung über geheime Signaturen, HTTPS und eine Wiederholungs-Logik bei Fehlern
Wie ein Webhook funktioniert
Ein Webhook besteht immer aus drei Bausteinen: dem auslösenden Ereignis, der Callback-URL und der übertragenen Nutzlast (Payload). Zunächst hinterlegt man im Quellsystem – etwa im Onlineshop oder beim Zahlungsdienstleister – eine URL, an die Benachrichtigungen gehen sollen, und wählt aus, bei welchen Ereignissen ausgelöst werden soll. Tritt das Ereignis ein, sendet das Quellsystem eine HTTP-Anfrage (meist ein POST) an genau diese Adresse. Im Nachrichtentext steckt die Payload: ein kompakter, maschinenlesbarer Datensatz – üblicherweise im Format JSON –, der beschreibt, was passiert ist, etwa die Bestellnummer, die Positionen und den Betrag.
Das empfangende System nimmt die Anfrage an einem eigens dafür eingerichteten Endpunkt entgegen, verarbeitet die Daten und bestätigt den Empfang mit einem HTTP-Statuscode wie 200. Bleibt diese Bestätigung aus – weil der Endpunkt kurz nicht erreichbar war –, versuchen die meisten Anbieter die Zustellung mehrfach erneut (Retry), oft mit wachsenden Zeitabständen. So gehen Ereignisse auch bei kurzen Störungen nicht verloren.
Absicherung: Signaturen und Wiederholungen
Weil eine Callback-URL grundsätzlich von jedem im Internet aufgerufen werden kann, brauchen Webhooks eine Absicherung. Verbreitet ist eine Signatur: Das Quellsystem berechnet aus der Nutzlast und einem geheimen Schlüssel eine Prüfsumme und schickt sie im Kopf der Anfrage mit. Das Zielsystem rechnet dieselbe Prüfsumme nach und akzeptiert die Nachricht nur, wenn beide übereinstimmen – so lassen sich gefälschte Aufrufe abweisen. Zusätzlich läuft die Übertragung über HTTPS, und der Endpunkt sollte identische Ereignisse ohne doppelte Wirkung verarbeiten (Idempotenz), da ein Retry dieselbe Meldung ein zweites Mal zustellen kann.
Webhook vs. API-Polling: Push statt Pull
Um denselben Zweck – Daten aus einem anderen System zu erhalten – gibt es zwei grundsätzliche Wege. Beim Polling ruft das eigene System in festen Abständen die API des Quellsystems auf und fragt: „Gibt es etwas Neues?“ Die meiste Zeit lautet die Antwort „nein“, sodass viele Anfragen ins Leere laufen. Fragt man selten ab, sind die Daten veraltet; fragt man häufig ab, erzeugt man unnötige Last und stößt schnell an die Rate-Limits der Schnittstelle.
Der Webhook dreht dieses Prinzip um: Das Zielsystem wartet passiv und wird nur dann aktiv, wenn das Quellsystem tatsächlich ein Ereignis meldet. Das Ergebnis ist geringere Last, weniger Datenverkehr und eine Aktualität nahe an der Echtzeit. Der Preis dafür ist ein öffentlich erreichbarer, dauerhaft verfügbarer Endpunkt, der eingehende Meldungen zuverlässig annimmt. In der Praxis kombinieren viele Integrationen beides: Webhooks für die schnelle Reaktion auf einzelne Ereignisse und ein gelegentliches Polling als Sicherheitsnetz, um verpasste Meldungen nachzuholen.
Webhooks im ERP-System
Im ERP sind Webhooks das Bindeglied für einen reaktionsschnellen Datenfluss zwischen Warenwirtschaft und der übrigen Systemlandschaft. Ein moderner Händler betreibt Shop, Marktplätze, Payment und Versand parallel – und jedes dieser Systeme kann dem ERP per Webhook melden, sobald etwas passiert. Läuft im Shop eine Bestellung ein, meldet ein Webhook dies sofort ans ERP, das den Auftrag anlegt, den Bestand reduziert und die Kommissionierung anstößt. Bucht ein Zahlungsdienstleister eine Zahlung, markiert ein weiterer Webhook den Auftrag als bezahlt und gibt ihn zum Versand frei.
Genauso funktioniert die Richtung nach außen: Ändert sich im ERP der Bestand eines Artikels, kann ein Webhook die angeschlossenen Verkaufskanäle informieren, damit die Bestandssynchronisation überall greift und Überverkäufe vermieden werden. Weil Webhooks meist über die REST-API eines Systems konfiguriert werden, gehören beide Konzepte eng zusammen: Die API stellt die Daten und die Verwaltung der Abonnements bereit, der Webhook liefert die Ereignisse aktiv aus.
Rolle von Middleware und iPaaS
Nicht jedes ERP kann jeden Webhook direkt entgegennehmen oder in beliebige Zielformate übersetzen. Hier kommt Middleware oder eine iPaaS-Plattform ins Spiel: Sie nimmt die Webhook-Meldungen zentral an, filtert und transformiert sie und reicht sie im passenden Format an das ERP oder weitere Systeme weiter. Das entkoppelt die Systeme voneinander, macht Fehler nachvollziehbar und erspart es, für jede neue Anbindung einen eigenen Endpunkt zu programmieren.
Grenzen und typische Stolperfallen
So effizient Webhooks sind, sie stellen auch Anforderungen. Der Endpunkt muss dauerhaft erreichbar sein – fällt er aus, gehen Meldungen zunächst verloren und werden erst durch Retries oder ein nachgelagertes Polling wiederhergestellt. Weil die Zustellung mehrfach erfolgen kann, muss der Empfänger dieselbe Meldung ohne Doppelbuchung verarbeiten. Und weil Ereignisse in unvorhersehbaren Wellen eintreffen können – etwa an einem Aktionstag mit vielen Bestellungen –, muss der Endpunkt kurzfristige Lastspitzen abfangen, idealerweise indem er die Meldung nur schnell annimmt und die eigentliche Verarbeitung in eine Warteschlange legt.
Ein weiterer Punkt ist die Reihenfolge: Webhooks garantieren nicht immer, dass Ereignisse in der Reihenfolge ankommen, in der sie ausgelöst wurden. Für ein sauberes Zusammenspiel sollte der Empfänger daher anhand von Zeitstempeln oder Statusfeldern prüfen, welcher Stand der aktuellste ist. Diese Anforderungen sind beherrschbar, gehören aber in jedes Integrations- und Implementierungsprojekt von Anfang an mitgedacht.
Praxisbeispiel
Beispiel: Zahlungseingang löst Versand aus
Ein Onlinehändler für Sportbekleidung nutzt einen externen Zahlungsdienstleister. Ein Kunde bestellt eine Jacke und zahlt per Sofortüberweisung. Sobald die Zahlung bestätigt ist, sendet der Zahlungsdienstleister einen Webhook an die im ERP hinterlegte Callback-URL – mit der Bestellnummer und dem Vermerk „bezahlt“ in der Payload.
Das ERP prüft die mitgeschickte Signatur, ordnet die Meldung dem offenen Auftrag zu und setzt ihn auf „bezahlt“. Damit fällt die Sperre für den Versand weg, der Auftrag wandert automatisch in die Kommissionierung, und ein Versandlabel wird erzeugt. Ohne Webhook müsste das ERP den Zahlungsstatus im Minutentakt abfragen; mit Webhook geschieht die Freigabe innerhalb von Sekunden nach dem Zahlungseingang – ganz ohne manuelles Zutun.
Häufige Fragen
Passende Leistungen
Fragen zu Webhook in deinem ERP-Projekt?
Wir beraten herstellerunabhängig – und setzen es auf Wunsch selbst um.