Stand: 1. November 2026 · Verantwortlich: Niclas Baldus, Baldux GmbH
Was ist ein Webhook?
Ein Webhook ist eine automatische Nachricht, die ein Programm an ein anderes schickt, sobald ein bestimmtes Ereignis eintritt. Statt dass das empfangende Programm regelmäßig nachfragt, ob es etwas Neues gibt, meldet sich das sendende Programm von selbst.
Ein Bild aus dem Alltag: Sie können alle zehn Minuten am Briefkasten nachsehen, ob Post da ist. Oder der Briefträger klingelt, wenn er etwas bringt. Der Webhook ist das Klingeln. Technisch ist er eine Anfrage über das Internet an eine Adresse, die das empfangende Programm dafür bereitstellt.
Auf Deutsch gibt es kein feststehendes Wort für Webhook. Treffend sind Ereignisbenachrichtigung oder Rückruf. Der Begriff verbindet „Web“ mit „Hook“, dem Haken, an dem sich ein anderes Programm einklinkt.
Webhook oder Abfrage: der Unterschied zur API
Bei einer klassischen API-Abfrage fragt Programm B bei Programm A nach, etwa alle fünf Minuten: Gibt es neue Aufträge? Das nennt man Polling. Meistens lautet die Antwort nein, trotzdem entsteht bei jeder Frage Aufwand. Und zwischen zwei Abfragen bleibt eine Lücke, in der B vom neuen Auftrag noch nichts weiß.
Beim Webhook dreht sich die Richtung um. Programm A meldet sich bei B, wenn ein neuer Auftrag angelegt wurde. B muss nicht fragen und erfährt zeitnah davon. Beide Wege ergänzen sich: Der Webhook sagt, dass etwas passiert ist. Weitere Einzelheiten holt sich das empfangende Programm bei Bedarf über die API.
- ✓API-Abfrage — Der Empfänger fragt regelmäßig nach. Einfach umzusetzen, aber mit Verzögerung und vielen leeren Antworten.
- ✓Webhook — Der Sender meldet sich beim Ereignis. Wenig Aufwand, zeitnah, aber der Empfänger muss erreichbar sein und die Nachricht prüfen.
- ✓Kombination — Der Webhook meldet das Ereignis, die API liefert die vollständigen Daten. Ein gelegentlicher Abgleich fängt verlorene Meldungen ab.
Aufbau einer Webhook-Nachricht
Eine Webhook-Nachricht ist in der Regel eine HTTP-Anfrage mit der Methode POST. Sie geht an eine Adresse, die der Empfänger vorher genannt hat, die sogenannte Webhook-URL. Im Inhalt steht meist im JSON-Format, was passiert ist und welcher Datensatz betroffen ist. Im Kopf der Anfrage stehen Zusatzangaben wie eine Signatur und eine eindeutige Kennung der Zustellung.
Ein vereinfachtes, allgemeines Beispiel, wie ein Ereignis zur Nachricht wird und was der Empfänger damit tut:
Ereignis
- Im Auftragssystem wird
- ein Auftrag angelegt
Nachricht
- POST /webhooks/auftraege
- {
- "ereignis": "auftrag.angelegt",
- "id": "A-2026-0815",
- "zeitpunkt": "2026-11-01T09:30:00Z"
- }
Prüfung beim Empfänger
- Signatur stimmt?
- Zustellung schon bekannt?
- Ereignis erwartet?
Antwort und Verarbeitung
- Antwort 200 OK
- Auftrag in die Versandplanung
- Details bei Bedarf über die API
Wie sicher sind Webhooks? Signatur, Wiederholung, Protokoll
Eine Webhook-URL ist eine offene Adresse im Internet. Jeder, der sie kennt, könnte dorthin eine Nachricht schicken. Deshalb muss der Empfänger prüfen können, dass eine Nachricht wirklich vom erwarteten Absender stammt und unterwegs nicht verändert wurde. Wie sicher ein Webhook ist, hängt vor allem davon ab, ob diese Prüfung stattfindet.
Das übliche Mittel ist eine Signatur. Sender und Empfänger teilen ein Geheimnis. Der Sender berechnet aus Nachricht und Geheimnis eine Prüfsumme, häufig nach dem Verfahren HMAC-SHA256, und schickt sie im Kopf der Anfrage mit. Der Empfänger rechnet nach. Stimmt das Ergebnis nicht, wird die Nachricht verworfen.
- ✓Signatur — Belegt Absender und Unverfälschtheit. Nachrichten ohne gültige Signatur werden abgelehnt.
- ✓Zeitstempel — Eine Nachricht, die zu alt ist, wird verworfen. Das erschwert das Wiedereinspielen abgefangener Nachrichten.
- ✓Verschlüsselte Verbindung — Webhooks sollten nur an Adressen mit HTTPS gehen, damit niemand mitlesen kann.
- ✓Wiederholung — Antwortet der Empfänger nicht, versucht der Sender es nach einer Weile erneut. Deshalb muss der Empfänger doppelte Zustellungen erkennen.
- ✓Protokoll — Jede Zustellung wird mit Zeitpunkt und Antwort festgehalten. So lässt sich klären, ob eine Meldung angekommen ist.
Beispiele: Wofür Unternehmen Webhooks nutzen
Webhooks lohnen sich überall dort, wo ein Ereignis in einem System eine Handlung in einem anderen auslösen soll. Sie ersetzen Abtippen, Weiterleiten per E-Mail und das ständige Nachsehen, ob sich etwas getan hat. Innerhalb eines Ablaufs können dabei auch mehrere Webhooks nacheinander verschiedene Systeme anstoßen, etwa erst die Versandplanung und dann das Kundenportal. Diese Beispiele kommen in vielen Unternehmen vor:
- ✓Auftrag angelegt — Der Onlineshop meldet eine neue Bestellung. Die Auftragsverwaltung legt den Auftrag an, ohne dass jemand die Bestellung abtippt.
- ✓Status geändert — Ein Auftrag wechselt auf Versandt. Das Kundenportal oder das Ticketsystem erfährt davon und zeigt den neuen Stand.
- ✓Zahlung eingegangen — Ein Zahlungsdienst meldet den Eingang. Der Auftrag kann zur Auslieferung freigegeben werden.
- ✓Formular abgeschickt — Eine Anfrage von der Website landet als neuer Vorgang im Vertrieb, mit allen Angaben.
- ✓Frist erreicht — Ein Vertrag läuft bald aus. Ein anderes System erhält eine Meldung und legt eine Wiedervorlage an.
- ✓Datensatz gelöscht — Ein Kunde wird im führenden System gelöscht. Die angebundenen Systeme erfahren davon und ziehen nach.
Webhooks in beide Richtungen
Ein Webhook hat immer zwei Seiten. Ausgehende Webhooks schickt Ihr System los, wenn bei Ihnen etwas passiert. Eingehende Webhooks empfängt Ihr System von anderen, etwa wenn ein Shop eine Bestellung meldet.
Für ausgehende Webhooks legen Sie fest, bei welchem Ereignis welche Adresse benachrichtigt wird und welche Daten mitgehen. Für eingehende Webhooks stellt Ihr System eine Adresse bereit und prüft jede Nachricht, bevor es sie verarbeitet. Schickt eine Fremdplattform eigene Signaturen, muss Ihr System deren Verfahren kennen.
In beiden Richtungen gilt: so wenige Daten wie nötig. Oft reicht es, Ereignis und Kennung zu übermitteln. Der Empfänger holt die Einzelheiten dann über die API, mit seinen eigenen Rechten.
Fehlerbehandlung: wenn ein Webhook nicht ankommt
Netzwerke sind nicht immer verfügbar, Server werden gewartet, und manchmal hat der Empfänger einen Fehler. Ein guter Umgang mit Webhooks rechnet damit. Diese Regeln haben sich bewährt:
- ✓Schnell antworten: Der Empfänger bestätigt den Eingang und verarbeitet die Nachricht danach, statt den Sender warten zu lassen.
- ✓Doppelte erkennen: Jede Zustellung hat eine Kennung. Kommt sie ein zweites Mal, wird sie nicht noch einmal verarbeitet.
- ✓Wiederholen mit Abstand: Der Sender versucht es mehrmals, mit wachsenden Pausen, und gibt irgendwann auf.
- ✓Aufgeben melden: Scheitert eine Zustellung endgültig, muss ein Mensch davon erfahren.
- ✓Reihenfolge nicht voraussetzen: Nachrichten können in anderer Reihenfolge ankommen, als sie verschickt wurden. Der Zeitstempel hilft beim Einordnen.
- ✓Abgleich als Netz: Ein regelmäßiger Abgleich über die API findet, was trotz allem verloren ging.
Webhook einrichten: Checkliste
Bevor Sie einen Webhook einrichten, sollten diese Fragen beantwortet sein. Sie gelten für jedes System, gleich ob Sie senden oder empfangen:
- ✓Welches Ereignis soll die Meldung auslösen, und unter welchen Bedingungen?
- ✓Welches System empfängt sie, und unter welcher Adresse?
- ✓Welche Daten gehen mit, und welche bewusst nicht?
- ✓Wie wird die Signatur gebildet, und wo liegt das gemeinsame Geheimnis?
- ✓Was passiert, wenn der Empfänger nicht erreichbar ist?
- ✓Wer wird informiert, wenn Zustellungen scheitern?
- ✓Wie wird getestet, bevor der Webhook im Betrieb läuft?
Signierte Webhooks in XGait
XGait ist ein Framework für Unternehmenssoftware nach Maß. Webhooks gehören dort zu den Bausteinen, mit denen wir Ihr System an andere anbinden, in beide Richtungen.
Ausgehende Webhooks sind signiert. Ausgelöst werden sie über Workflows: Ein Ereignis wie „Eintrag erstellt“, „Feld ändert sich“ oder „Status wechselt“ startet unter den festgelegten Bedingungen eine Aktion, die den Webhook sendet. Scheitert eine Zustellung endgültig, meldet XGait das in der App der Person, die den Webhook angelegt hat.
Eingehende Webhooks nimmt XGait an einer eigenen Adresse an, auch mit Signaturprüfung nach dem Verfahren einer Fremdplattform. Weitere Daten können angebundene Systeme über die REST-API lesen, die jedes Objekt automatisch erhält. Bank- und Zahlungsschnittstellen, E-Rechnung und Behördenschnittstellen gehören nicht zu den Anbindungen, die wir einrichten.
Standardmäßig ist in XGait keine KI aktiv. Künftig lässt sich die Plattform-KI gesondert in Ihrer Instanz zuschalten, mit zusätzlichen Bedingungen und gesonderter Abrechnung. Auch dann sendet sie keine Webhooks.
Ihr Weg zu Webhooks mit XGait
Welche Ereignisse bei Ihnen andere Systeme anstoßen sollen, klären wir im Erstgespräch. Danach nehmen wir Ihre Abläufe auf, und Sie erhalten einen Umsetzungsvorschlag mit Festpreis. Wir richten Objekte, Workflows und Webhooks ein, Sie testen und geben frei.
Was Ihr Ablauf braucht, bauen wir. Was die Plattform noch nicht kann, ergänzen wir.