Webhook

Der Unterschied zur klassischen API-Abfrage: Bei der API fragt System B regelmäßig bei System A nach ("gibt es was Neues?") — mit Verzögerung und unnötiger Last. Beim Webhook meldet sich System A von selbst, in dem Moment, in dem etwas passiert. Für Automatisierungen bedeutet das: Prozesse starten in Sekunden statt beim nächsten Abfrage-Intervall.

In KI-Agenten-Projekten sind Webhooks die typischen Startpunkte: Neue E-Mail, neues Support-Ticket, neuer Shop-Auftrag, ausgefülltes Formular — jedes Ereignis stößt sofort den zuständigen Verarbeitungsprozess an.

Professionelle Umsetzungen sichern Webhooks ab: Signaturprüfung (kommt die Nachricht wirklich vom echten Absender?), Wiederholungslogik bei Ausfällen und Protokollierung. So geht kein Ereignis verloren, auch wenn ein System kurzzeitig nicht erreichbar ist.

Drei Punkte entscheiden über die Zuverlässigkeit im Alltag. Erstens Doppel-Zustellungen: Viele Systeme senden ein Ereignis im Zweifel lieber zweimal als gar nicht — die empfangende Automatisierung muss erkennen, dass es sich um dasselbe Ereignis handelt, sonst entstehen doppelte Datensätze oder doppelte E-Mails. Zweitens die Reihenfolge: Webhooks kommen nicht garantiert in der Reihenfolge an, in der die Ereignisse passiert sind — Prozesse, bei denen die Reihenfolge zählt (erst Auftrag, dann Änderung), brauchen eine entsprechende Prüfung. Drittens die Fehlerseite: Was passiert, wenn der Empfänger gerade nicht erreichbar ist? Gute Absender wiederholen die Zustellung, gute Empfänger puffern eingehende Ereignisse, bevor sie sie verarbeiten.

Für den Überblick im Betrieb hat sich ein zentrales Ereignis-Protokoll bewährt: jede eingegangene Meldung mit Zeitstempel, Quelle und Verarbeitungsstatus. Damit lässt sich jederzeit beantworten, ob ein bestimmtes Ereignis angekommen und verarbeitet wurde — die häufigste Frage, wenn im Prozess einmal etwas fehlt.

Im laufenden Betrieb ist das größte Risiko bei Webhooks die stille Panne: Ein Empfänger antwortet nicht mehr, der sendende Dienst gibt irgendwann auf — und niemand bemerkt, dass seit Stunden keine Ereignisse ankommen. Professionelle Setups überwachen daher aktiv: Ein Monitoring prüft, ob in einem zu erwartenden Zeitraum Ereignisse eingegangen sind, und alarmiert bei Ausbleiben. Einfaches Indiz: Wenn ein Shop täglich regelmäßig Bestellungen sendet und seit Stunden keine eingegangen ist, stimmt etwas nicht.

Zum Betriebskonzept gehört außerdem ein definierter Prozess für Webhook-Fehler: Welche Ereignisse konnten nicht verarbeitet werden, aus welchem Grund, und wie werden sie nachgeholt? Viele sendende Systeme speichern fehlgeschlagene Zustellungen für eine begrenzte Zeit und erlauben eine Wiederholung — dieses Zeitfenster muss bekannt sein. Fehlermeldungen sollten nicht still in Log-Dateien verschwinden, sondern in einem Kanal auftauchen, den jemand täglich sieht. Ein einfaches Dashboard mit Ampelstatus pro Webhook-Strecke erfüllt diesen Zweck zuverlässig.

Ein Webhook-Empfänger ist eine nach außen offene Adresse — jeder, der sie kennt, kann grundsätzlich Daten dorthin schicken. Genau deshalb ist die Echtheitsprüfung nicht optional, sondern die Grundlage jeder seriösen Umsetzung. Verbreitet ist die Signaturprüfung: Der sendende Dienst versieht jede Meldung mit einer kryptografischen Signatur, die der Empfänger prüft, bevor er die Daten verarbeitet. Ohne diese Prüfung könnte ein Angreifer gefälschte Ereignisse einschleusen und so etwa unberechtigte Vorgänge auslösen. Ergänzend gehört die Übertragung verschlüsselt, damit die Inhalte unterwegs nicht mitgelesen werden können.

Der zweite wichtige Aspekt ist der Datenschutz, denn Webhooks transportieren oft personenbezogene Daten — eine neue Bestellung enthält Name und Adresse, ein Kontaktformular die Angaben des Interessenten. Damit gelten die üblichen Grundsätze: Es sollten nur die Datenfelder übertragen werden, die für den nachfolgenden Prozess wirklich nötig sind, und der Empfangs- sowie Verarbeitungsweg muss datenschutzkonform gestaltet sein. Fließen Daten über einen Cloud-Dienst als Zwischenstation, gehört dieser als Auftragsverarbeiter eingebunden, und der Serverstandort will bedacht sein.

Praktisch heißt das: Die Empfangsadresse eines Webhooks wird wie ein Zugang behandelt, nicht wie eine harmlose Benachrichtigung. Sie ist nicht öffentlich bekannt, wird abgesichert, und ihr Datenverkehr wird protokolliert — so bleibt nachvollziehbar, welche Ereignisse eingegangen sind und ob sie echt waren.