Webhook

Ein Webhook kehrt das übliche Kommunikationsmuster um. Bei einer normalen API fragt ein Client aktiv Daten beim Server an. Bei einem Webhook ist es umgekehrt: Der Server ruft den Client an, sobald etwas passiert. Deshalb wird ein Webhook auch als Reverse-API oder HTTP-Callback bezeichnet.

Der Ablauf ist einfach. Das Zielsystem stellt eine öffentlich erreichbare Endpunkt-URL bereit und registriert sie beim Quellsystem für bestimmte Ereignistypen. Tritt eines dieser Ereignisse ein, schickt das Quellsystem eine HTTP-POST-Anfrage an diese URL, deren Body die Ereignisdaten meist als JSON enthält.

Der entscheidende Vorteil ist die Echtzeitfähigkeit bei minimalem Ressourcenverbrauch: Daten fließen genau dann, wenn es etwas Neues gibt, statt durch dauerhaftes Nachfragen Last und Verzögerung zu erzeugen.

Beim Polling fragt ein System in festen Abständen wiederholt eine API ab, um zu prüfen, ob neue Daten vorliegen. Das ist einfach umzusetzen, verschwendet aber Ressourcen, weil die meisten Anfragen ohne neues Ergebnis bleiben, und erzeugt zwangsläufig eine Verzögerung zwischen Ereignis und Reaktion.

Ein Webhook löst beide Probleme. Es gibt keine Leeranfragen, und die Benachrichtigung erfolgt nahezu unmittelbar. Der Preis dafür ist eine etwas höhere Komplexität: Das Zielsystem muss einen erreichbaren Endpunkt betreiben, eingehende Anfragen absichern und auf Zustellfehler vorbereitet sein.

Für ereignisgetriebene Szenarien ist der Webhook deshalb fast immer die effizientere Wahl, während Polling eher für seltene oder unkritische Abfragen geeignet ist. In der Praxis werden beide Ansätze gelegentlich kombiniert: Webhooks liefern Ereignisse in Echtzeit, und ein gelegentliches Polling dient als Sicherungsnetz, um eventuell verpasste Benachrichtigungen nachträglich auszugleichen.

Da ein Webhook-Endpunkt öffentlich erreichbar ist, muss er gegen Missbrauch geschützt werden. Verbreitet ist eine Signaturprüfung: Das Quellsystem signiert die Nutzdaten mit einem geheimen Schlüssel, das Zielsystem berechnet die Signatur nach und akzeptiert nur passende Anfragen. So lässt sich die Echtheit jeder Benachrichtigung verifizieren.

Für die Zuverlässigkeit sind Wiederholungen und Idempotenz entscheidend. Schlägt eine Zustellung fehl, sollte das Quellsystem den Aufruf erneut versuchen. Das Zielsystem wiederum muss damit rechnen, dieselbe Benachrichtigung mehrfach zu erhalten, und sie idempotent verarbeiten, damit kein Ereignis doppelt wirkt.

Empfehlenswert ist außerdem, eingehende Webhooks schnell anzunehmen und die eigentliche Verarbeitung asynchron in eine Warteschlange auszulagern, um Zeitüberschreitungen zu vermeiden.

Webhooks sind das Bindeglied vieler Automatisierungen. Plattformen für Workflow-Automatisierung starten ganze Prozessketten, sobald ein Webhook eintrifft, etwa wenn ein Formular ausgefüllt oder eine Bestellung ausgelöst wird. So entstehen reaktive Systeme, die ohne manuelles Eingreifen auf Ereignisse reagieren.

In KI-Lösungen verbinden Webhooks Modelle und Agenten mit der realen Geschäftswelt. Ein eingehender Webhook kann eine Analyse durch ein Sprachmodell anstoßen, dessen Ergebnis anschließend wieder per Webhook oder API an Folgesysteme verteilt wird. Damit werden LLM-Workflows ereignisgesteuert in bestehende Abläufe eingebettet.

Gerade bei länger laufenden KI-Aufgaben sind Webhooks praktisch: Statt synchron auf das Ergebnis einer aufwendigen Modellberechnung zu warten, stößt das System die Aufgabe an und lässt sich per Webhook benachrichtigen, sobald das Ergebnis vorliegt. Das hält Schnittstellen reaktionsfähig und entkoppelt die Verarbeitung von der ursprünglichen Anfrage.

Ein Webhook-Endpunkt ist technisch ein gewöhnlicher HTTP-Endpunkt, der POST-Anfragen entgegennimmt. Wichtig ist, dass er die Anfrage zügig mit einem Statuscode im Erfolgsbereich bestätigt, damit das Quellsystem die Zustellung nicht als gescheitert wertet und unnötig wiederholt. Die fachliche Verarbeitung sollte davon entkoppelt erfolgen.

In der Praxis hat sich ein dreistufiges Vorgehen bewährt: empfangen, validieren, einreihen. Zunächst wird die Signatur geprüft und der Payload grob auf Plausibilität kontrolliert. Anschließend wird das Ereignis in eine Warteschlange geschrieben und sofort bestätigt. Erst danach übernimmt ein Hintergrundprozess die eigentliche, möglicherweise zeitintensive Verarbeitung.

Für die Fehlersuche ist es hilfreich, eingehende Webhooks protokolliert und mit einer eindeutigen Ereignis-Kennung versehen zu speichern. So lassen sich Zustellungen nachvollziehen und im Problemfall gezielt erneut verarbeiten, ohne das Quellsystem zu belasten.