Was ist ein Webhook? Funktion und Unterschied zur API einfach erklärt

Was ist ein Webhook, in einem Satz erklärt?

Ein Webhook ist eine automatische HTTP Anfrage, die ein System an eine von Ihnen festgelegte Adresse schickt, sobald ein bestimmtes Ereignis eintritt. Das heißt, Sie fragen nicht nach Daten, sondern die Gegenseite meldet sich bei Ihnen. Zahlungsbestätigungen, neue Formulareinträge und Code Pushes erreichen Sie so sofort.

Zunächst hilft ein einfaches Bild. Wenn Sie den Paketdienst jede Stunde anrufen und fragen, ob Ihr Paket da ist, nennt man das Polling. Wenn der Paketdienst Ihnen eine SMS schickt, sobald das Paket vor der Tür liegt, ist das ein Webhook. Im zweiten Fall sparen Sie Zeit, und der Dienst muss keine unnötigen Anrufe beantworten.

In diesem Beitrag beantworten Talha Aslan und Team die Frage, was ist ein Webhook, auf konzeptioneller Ebene, aber mit genug Tiefe für echte Projekte. Zunächst erklären wir das ereignisbasierte Push Modell. Danach vergleichen wir Webhooks mit API Polling und WebSocket in einer Tabelle. Schließlich geht es um Signaturprüfung, Wiederholungen, Idempotenz und Sicherheit. Lange Codeblöcke lassen wir bewusst weg, denn die Logik soll klar werden.

Was ist ein Webhook im Sinne von „ereignisbasiertem Push“?

Ereignisbasierter Push bedeutet, dass Daten fließen, wenn ein Ereignis eintritt, und nicht, wenn jemand sie anfordert. Bei einem klassischen API Aufruf geht der Client zum Server und sagt: „Gib mir die neuesten Bestellungen.“ Beim Webhook dreht sich die Richtung um. Der Server meldet sich bei der Adresse des Clients, sobald das Ereignis passiert.

Konkret hat das Modell drei Teile. Erstens das System, das das Ereignis erzeugt, zum Beispiel ein Zahlungsanbieter. Zweitens die Definition des Ereignisses, etwa „Zahlung erfolgreich“ oder „Abo gekündigt“. Drittens die Empfangsadresse auf Ihrem Server, also der Endpunkt. Tritt das Ereignis ein, schickt der Anbieter meist eine POST Anfrage mit JSON Inhalt an diesen Endpunkt.

Ein Webhook ist also kein neues Protokoll. Er ist eine Vereinbarung über ganz normales HTTP: „Wenn dieses Ereignis eintritt, benachrichtige jene Adresse in diesem Format.“ Diese Einfachheit erklärt seine Verbreitung. Zahlungsplattformen, Code Hosting Dienste, Formulartools, E-Mail Dienste und CRM Systeme bieten ihn fast standardmäßig an.

Wie funktioniert ein Webhook Schritt für Schritt?

Damit der Ablauf greifbar wird, gehen wir einen typischen Lebenszyklus durch. Die Details unterscheiden sich je nach Anbieter. Das Grundgerüst bleibt allerdings fast gleich.

1. Sie richten auf Ihrem Server eine öffentliche Empfangsadresse ein, die über HTTPS läuft.
2. Sie hinterlegen diese Adresse im Dashboard oder über die API des Anbieters und wählen die gewünschten Ereignisse.
3. Der Anbieter gibt Ihnen ein gemeinsames Geheimnis (Secret), oder Sie legen es selbst fest.
4. Tritt das Ereignis ein, verpackt der Anbieter es als JSON, signiert es mit dem Secret und sendet es per POST an Ihre Adresse.
5. Sie prüfen die Signatur, legen die Anfrage in eine Warteschlange und antworten schnell mit einem 2xx Statuscode.
6. Die eigentliche Arbeit, etwa die Bestellung aktualisieren oder eine E-Mail senden, läuft danach in einem eigenen Hintergrundprozess.
7. Kommt keine Antwort oder ein Fehler zurück, versucht der Anbieter es nach seiner eigenen Richtlinie später erneut.

Den fünften Schritt überspringen Teams am häufigsten. Viele erledigen die ganze Arbeit innerhalb der Anfrage. Die Antwort kommt dann zu spät, und der Anbieter wertet die Zustellung als gescheitert. Auch die offizielle Webhook Dokumentation von Stripe empfiehlt, schnell eine erfolgreiche Antwort zu senden, bevor komplexe Logik läuft.

Was ist der Unterschied zwischen Webhook und API?

Kurz gesagt ist eine API eine Tür, und ein Webhook ist die Klingel, die von der anderen Seite läutet. Eine API ist ein Regelwerk, über das eine Software mit einer anderen spricht. Sie rufen sie auf, wann immer Sie wollen. Ein Webhook gehört meist zu einer API, doch hier startet der Anbieter das Gespräch.

Deshalb ist die Frage „Webhook oder API?“ etwas irreführend. Die meisten Integrationen nutzen beides. Zum Beispiel meldet ein Zahlungsanbieter per Webhook: „Diese Zahlung war erfolgreich.“ Danach fragen Sie mit der Zahlungs ID die API desselben Anbieters ab, um die verlässlichen Details zu holen.

Wenn Sie die Grundlagen von APIs suchen, lesen Sie unseren Beitrag Was ist eine API, dort geht es um Endpunkte, Anfragen und Antworten. Das flexible Abfragemodell finden Sie in unserem Vergleich von GraphQL und REST. Hier konzentrieren wir uns nur auf die Webhook Seite.

Dabei hilft also eine praktische Faustregel. Brauchen Sie „Sag mir Bescheid, wenn sich etwas ändert“, denken Sie an einen Webhook. Brauchen Sie „Ich hole die Daten, wann ich will“, reicht ein direkter API Aufruf.

Wie entscheiden Sie zwischen Polling und Webhook?

Polling bedeutet, dass der Client in festen Abständen fragt, ob es etwas Neues gibt. Die Einrichtung ist leicht, denn Sie brauchen keine öffentliche Adresse. Allerdings kommen die meisten Anfragen leer zurück und verbrauchen auf beiden Seiten Ressourcen.

Zudem hängt die Verzögerung beim Polling von Ihrem Intervall ab. Fragen Sie alle fünf Minuten, bemerken Sie eine Zahlung im schlechtesten Fall fünf Minuten später. Verkürzen Sie das Intervall, steigt die Zahl der Anfragen. Dann stoßen Sie womöglich an das Rate Limit des Anbieters.

Ein Webhook kommt dagegen im Moment des Ereignisses und erzeugt keine leeren Anfragen. Andererseits müssen Sie eine Empfangsadresse veröffentlichen, absichern und für verpasste Ereignisse planen. In der Praxis ist ein Mischmodell oft am robustesten: Webhooks für sofortige Meldungen und ein regelmäßiger Abgleich per Polling.

Beispielszenario: Ein Onlineshop erhält Zahlungsbestätigungen per Webhook. Zusätzlich holt er einmal pro Nacht die Zahlungen des Tages über die API des Anbieters und vergleicht sie mit den eigenen Daten. Somit fällt selbst eine Meldung, die während einer Serverwartung verloren ging, am nächsten Morgen auf.

Webhook, API Polling und WebSocket im Vergleich

Diese drei Ansätze verwechseln viele, deshalb lohnt der Vergleich. Die Tabelle zeigt, welcher Ansatz welche Frage beantwortet. Die Angaben sind konzeptionell; die echte Leistung hängt von Ihrer Infrastruktur ab.

Mehr zu WebSocket lesen Sie in unserem Beitrag Was ist WebSocket. Kurz gesagt liefert WebSocket Live Daten an eine Benutzeroberfläche. Ein Webhook transportiert dagegen Ereignismeldungen zwischen zwei Servern.

Was steht in einer Webhook Anfrage?

Eine Webhook Anfrage ist ein gewöhnlicher HTTP POST. Trotzdem folgt ihr Inhalt einem Muster. Der Inhalt ist meist JSON und enthält Ereignistyp, eindeutige ID, Zeitpunkt und das betroffene Objekt.

• Ereignistyp: Ein Feld wie „payment succeeded“ oder „push“, das sagt, was passiert ist.
• Ereignis ID: Ein eindeutiger Wert pro Ereignis, entscheidend zum Aussortieren von Duplikaten.
• Zeitstempel: Wann das Ereignis entstand; er hilft gegen erneut abgespielte Anfragen.
• Datenobjekt: Der eigentliche Inhalt, etwa eine Zahlung, ein Formulareintrag oder eine Änderung im Repository.
• Signatur Header: Eine mit dem Secret erzeugte Signatur des Inhalts, die den Absender belegt.

Konkret unterscheiden sich die Namen der Header je nach Anbieter. GitHub schickt die Signatur zum Beispiel in einem eigenen Header als HMAC auf Basis von SHA 256. Stripe packt dagegen Signatur und Zeitstempel gemeinsam in seinen Header. Halten Sie sich daher immer an die aktuelle Dokumentation Ihres Dienstes.

Falls Datenformate Sie verwirren, ist unser Beitrag zum Unterschied zwischen YAML und JSON ein guter Einstieg.

Warum ist die Prüfung der Webhook Signatur Pflicht?

Ihre Empfangsadresse ist öffentlich. Daher kann jeder, der sie kennt, eine gefälschte Meldung „Zahlung erfolgreich“ schicken. Ohne Signaturprüfung bestätigt Ihr System womöglich eine Bestellung, die niemand bezahlt hat. Das ist die wichtigste Grundregel der Webhook Sicherheit.

Die Lösung heißt daher HMAC. HMAC (Hash based Message Authentication Code) verbindet die Nachricht mit einem geheimen Schlüssel und erzeugt über eine Hashfunktion einen Prüfwert. Die Methode beschreibt RFC 2104. Weil nur Sie und der Anbieter das Secret kennen, kann sonst niemand eine gültige Signatur erzeugen.

Konkret sieht die Logik so aus. Der Anbieter signiert den Inhalt mit dem Schlüssel und legt die Signatur in einen Header. Danach signieren Sie den rohen eingehenden Inhalt mit demselben Schlüssel. Stimmen beide Werte überein, ist die Anfrage echt; sonst lehnen Sie sie ab.

Zwei feine Punkte zählen hier. Erstens berechnen Sie die Signatur über den rohen Inhalt. Wenn Sie das JSON parsen und neu schreiben, ändern sich Leerzeichen, und die Signatur passt nicht mehr. Zweitens vergleichen Sie die Werte mit einer Funktion in konstanter Laufzeit. Auch die GitHub Anleitung zur Prüfung von Zustellungen rät dazu statt eines einfachen Gleichheitsvergleichs.

Welche Fehler passieren bei der HMAC Prüfung am häufigsten?

Die Fehler aus der Praxis folgen wenigen Mustern. Nutzen Sie die Liste also als Checkliste, wenn Sie Ihren Code durchsehen.

• Kein Zugriff auf den rohen Inhalt, weil das Framework ihn automatisch parst.
• Das Test Secret im Livebetrieb verwenden oder umgekehrt.
• Das Secret fest im Code hinterlegen und ins Repository hochladen.
• Vergleichen, ohne das Präfix im Signatur Header zu entfernen, etwa den Namen des Algorithmus.
• Den Zeitstempel nie prüfen und damit Replay Angriffen die Tür öffnen.
• Trotz falscher Signatur mit 200 antworten und den Fehler still schlucken.

Wählen Sie vor allem für das Secret einen langen, zufälligen Wert. Einen starken Wert erzeugen Sie schnell mit unserem Passwort Generator. Speichern Sie das Secret in einer Umgebungsvariable oder einem Secrets Manager. Außerdem sollten Sie es regelmäßig erneuern; viele Anbieter akzeptieren während des Wechsels zwei Secrets gleichzeitig.

Verwechseln Sie Signaturprüfung nicht mit tokenbasierter Anmeldung. Für Benutzersitzungen gilt die Struktur aus unserem Beitrag über JWT. Beim Webhook prüfen Sie dagegen Herkunft und Unversehrtheit einer Nachricht, nicht einen Nutzer.

Wie funktionieren Wiederholungsversuche bei Webhooks?

Allerdings ist das Internet nicht perfekt. Ihr Server ist vielleicht gerade in Wartung, das Netz bricht ab, oder Ihr Code wirft einen Fehler. Deshalb wiederholen seriöse Anbieter gescheiterte Zustellungen nach einer festen Richtlinie.

Die Grundregel lautet: Bekommt der Anbieter keine 2xx Antwort oder gar keine Antwort in der vorgesehenen Zeit, wertet er die Zustellung als gescheitert. Dann versucht er es mit wachsenden Abständen erneut, bekannt als Exponential Backoff. Laut Stripe Dokumentation wiederholt Stripe gescheiterte Ereignisse im Livemodus über mehrere Tage. GitHub stellt gescheiterte Zustellungen dagegen nicht automatisch erneut zu; Sie stoßen das selbst im Dashboard oder über die API an.

Die Richtlinien unterscheiden sich also stark. Merken Sie sich Anzahl der Versuche, Abstände oder Zeitlimits nicht als feste Zahlen. Prüfen Sie stattdessen den aktuellen Wert in der offiziellen Dokumentation des Anbieters.

Ihre Aufgabe ist somit klar. Nehmen Sie die Anfrage schnell an, legen Sie die Arbeit in eine Warteschlange und antworten Sie mit 2xx. So löst eine langsame Datenbankabfrage keine unnötigen Wiederholungen aus. Wählen Sie Fehlercodes zudem bewusst: 4xx bei falscher Signatur und 5xx bei vorübergehenden Störungen senden dem Anbieter das richtige Signal.

Warum ist Idempotenz bei Webhooks so wichtig?

Wiederholungen haben eine natürliche Folge: Dasselbe Ereignis kann Sie mehrfach erreichen. Stripe weist ausdrücklich darauf hin, dass ein Endpunkt dasselbe Ereignis gelegentlich mehr als einmal erhalten kann. Legt Ihr Code bei jeder Anfrage eine Bestellung an, bekommt Ihr Kunde womöglich zwei Lieferungen oder zwei Rechnungen.

Idempotenz bedeutet, dass ein Vorgang einmal oder zehnmal ausgeführt dasselbe Ergebnis liefert. Bei Webhooks ist der praktischste Weg, die Ereignis ID zu speichern. Kommt eine neue Anfrage, prüfen Sie zuerst die ID. Haben Sie das Ereignis schon verarbeitet, tun Sie nichts und antworten mit 2xx.

Zur Absicherung setzen Sie in der Datenbank eine Unique Constraint auf die Spalte mit der Ereignis ID. Dann gelingt selbst bei zwei gleichzeitigen Anfragen nur ein Schreibvorgang. Das Konzept erklären wir ausführlich in unserem Beitrag Was ist Idempotenz, daher wiederholen wir es hier nicht.

Zudem ist die Reihenfolge heikel. Ereignisse kommen nicht immer in der Reihenfolge an, in der sie entstanden. So kann „Abo aktualisiert“ vor „Abo erstellt“ eintreffen. Stützen Sie sich deshalb beim Ändern eines Status auf den Zeitstempel, oder holen Sie den aktuellen Stand des Objekts über die API.

Welche Sicherheitsmaßnahmen brauchen Webhooks?

Die Signaturprüfung ist ein guter Anfang, reicht allein aber nicht. Sie brauchen mehrere Schichten. Gehen Sie die folgende Checkliste vor dem Livegang mit Ihrem Team durch.

1. Veröffentlichen Sie die Empfangsadresse nur über HTTPS; schicken Sie keine Geheimnisse über einfaches HTTP.
2. Prüfen Sie jede Signatur über den rohen Inhalt mit einem Vergleich in konstanter Laufzeit.
3. Kontrollieren Sie den Zeitstempel und lehnen Sie Anfragen außerhalb eines vernünftigen Zeitfensters ab.
4. Speichern Sie Ereignis IDs und sortieren Sie Duplikate aus.
5. Vertrauen Sie dem Inhalt nicht blind; holen Sie bei kritischen Vorgängen den aktuellen Stand über die API.
6. Validieren Sie eingehende Daten und ignorieren Sie unerwartete Felder.
7. Nutzen Sie einen schwer zu erratenden Pfad, aber nie als einzige Schutzschicht.
8. Veröffentlicht der Anbieter IP Bereiche, kommt eine Allowlist als zusätzliche Schicht infrage.
9. Führen Sie Logs, maskieren Sie aber sensible Felder wie Kartendaten oder personenbezogene Daten.

Transportieren Webhooks personenbezogene Daten, denken Sie auch an Ihre Pflichten nach DSGVO. Dieser Beitrag ist keine Rechtsberatung; klären Sie Fragen zur Datenverarbeitung mit Ihrer Rechtsberatung.

Wie nutzen Sie Webhooks für Zahlungsbenachrichtigungen?

Zahlungen sind vor allem der kritischste Einsatzfall. Beispielszenario: Ein Kunde gibt im Checkout seine Kartendaten ein, schließt den 3D Secure Schritt ab und schließt dann den Browser. Verlassen Sie sich nur auf die Weiterleitung im Browser, bestätigen Sie diese Bestellung nie.

Der Zahlungsanbieter schickt Ihrem Server jedoch einen Webhook, sobald die Transaktion abgeschlossen ist. Sie prüfen die Signatur, kontrollieren die Ereignis ID und setzen die Bestellung auf „bezahlt“. Danach laufen Bestätigungsmail und Lagerbuchung aus der Warteschlange.

Daraus folgt die goldene Regel für Zahlungsintegrationen: Knüpfen Sie den endgültigen Status an die Meldung zwischen den Servern, nicht an die Browserweiterleitung. Scheitert der Checkout immer wieder an der Verifizierung, hilft Ihnen unser Beitrag 3D Secure fehlgeschlagen weiter.

Zudem kommen Erstattungen, Rückbuchungen und Aboverlängerungen meist ebenfalls per Webhook. Ignorieren Sie diese, weicht Ihre Buchhaltung still von der Realität ab.

Was bringen Webhooks bei Formularen und CRM Anbindungen?

Das zweite häufige Szenario betrifft Formulare und Kundenbeziehungsmanagement. Füllt jemand zum Beispiel das Anfrageformular auf Ihrer Website aus, löst das Formulartool einen Webhook aus. Diese Anfrage schreibt den Eintrag sofort ins CRM, und Ihr Vertrieb bekommt eine Meldung.

Mit Polling erschiene derselbe Lead womöglich erst Minuten später. In vielen Branchen verhält sich ein Lead, den Sie schnell zurückrufen, ganz anders als einer, den Sie erst Stunden später erreichen. Außerdem kann ein Webhook Werbequelle, UTM Parameter und Seiteninformationen gleich mitliefern.

Wie wir diesen Ablauf von Anfang bis Ende planen, zeigt unser Beitrag zur CRM Anbindung einer Website. Webhooks funktionieren auch in umgekehrter Richtung. Wechselt eine Verkaufschance im CRM auf „gewonnen“, kann automatisch ein Eintrag in Ihrem Buchhaltungs oder Projekttool entstehen.

Beim Code Hosting läuft es ebenso. GitHub stößt per Webhook Ihren Build Server an, sobald jemand einen neuen Commit pusht. Dann startet die Pipeline für kontinuierliche Integration, ohne dass jemand einen Knopf drückt.

Wie testen Sie einen Webhook Endpunkt?

Webhooks zu testen ist knifflig, denn nicht Sie senden die Anfrage, sondern die Gegenseite. Trotzdem erleichtern die meisten Anbieter das. Im Dashboard finden Sie meist eine Option für Testereignisse, eine Liste vergangener Zustellungen und den Antwortcode jeder Zustellung.

• Beginnen Sie in einer Sandbox mit eigenem Endpunkt und eigenem Secret.
• Für die lokale Entwicklung nutzen Sie das offizielle Kommandozeilentool des Anbieters, falls es Ereignisse an Ihren Rechner weiterleitet.
• Testen Sie gültige Signaturen, ungültige Signaturen, alte Zeitstempel und doppelte Zustellungen einzeln.
• Beobachten Sie die Antwortzeiten im Zustellverlauf des Anbieters.
• Verfolgen Sie nach dem Start die Fehlerquote in den ersten Tagen genau.

Richten Sie lokal eine Python Umgebung für Tests ein, stoßen Sie womöglich auf Fehler mit der Umgebung. Einen häufigen Fall lösen wir in unserem Beitrag zum Fehler externally managed environment bei pip. So installieren Sie Ihre Testtools, ohne das System Python zu beschädigen.

Wie bleibt die Verarbeitung von Webhooks bei Last schnell?

Wächst der Verkehr, ist ein Empfänger, der jede Anfrage synchron abarbeitet, das größte Risiko. Stellen Sie sich einen Aktionstag mit Hunderten Zahlungsereignissen pro Minute vor. Schreibt jedes davon direkt in die Datenbank, verschickt eine E-Mail und bucht den Bestand, werden die Antworten langsam. Der Anbieter wiederholt, und die Last vervielfacht sich.

Daher erledigt der Empfänger in einer soliden Architektur nur drei Aufgaben. Er prüft die Signatur, schreibt das Ereignis in eine Warteschlange und antwortet mit 2xx. Eigene Worker Prozesse arbeiten die Warteschlange dann im eigenen Tempo ab. Folglich blockiert eine Verlangsamung den Empfänger nicht.

Eine Dead Letter Queue für Ereignisse, deren Verarbeitung scheitert, ist ebenfalls eine gute Gewohnheit. Nach der Fehlerbehebung verarbeiten Sie diese Ereignisse erneut. Auch ein Cache für häufig gelesene Referenzdaten senkt die Last; dazu mehr in unserem Beitrag über Caching.

Schließlich brauchen Sie Monitoring. Behalten Sie Anzahl der Ereignisse, Quote der Signaturfehler, Länge der Warteschlange und Verarbeitungszeit in einem Dashboard im Blick. Dann erkennen Sie Probleme, bevor Kunden sie spüren.

Gibt es Fälle, in denen Sie keinen Webhook nutzen sollten?

Ja, denn Webhooks passen nicht zu jedem Bedarf. Bietet der Anbieter keine Webhooks an, bleibt Ihnen nur Polling. Ebenso gilt: Können Sie Ihren Server nicht nach außen öffnen, etwa in einem geschlossenen Firmennetz, empfangen Sie keine eingehenden Anfragen.

Auch für Live Daten beim Nutzer im Browser ist ein Webhook keine direkte Lösung. Der Browser ist kein HTTP Server und nimmt keine eingehenden Anfragen an. In diesem Fall landet der Webhook auf Ihrem Server, und Sie leiten die Daten per WebSocket oder über einen ähnlichen Kanal an die Oberfläche weiter.

Bei sehr hohem Datenvolumen kann eine HTTP Anfrage pro Ereignis ineffizient werden. Für solche Szenarien eignen sich Message Queues oder Plattformen für Event Streaming oft besser. Zusammengefasst ist der Webhook der einfachste und verbreitetste Weg für Ereignismeldungen zwischen Servern bei niedrigem bis mittlerem Volumen.

Welche Begriffe verwechseln viele mit Webhooks?

Wer wissen will, was ist ein Webhook, hält oft einige Nachbarbegriffe für dasselbe. Diese Verwechslung kann zu schlechten Architekturentscheidungen führen. Deshalb trennen wir die häufigsten Paare kurz voneinander.

• Callback: Ein allgemeines Programmierkonzept, also eine Funktion, die nach Abschluss einer Aufgabe läuft. Ein Webhook überträgt diese Idee per HTTP zwischen Systemen.
• Pushbenachrichtigung: Die Meldung auf Ihrem Smartphone, gedacht für Endnutzer. Ein Webhook geht an einen Server, kein Nutzer sieht ihn.
• Reverse API: Manche Quellen nennen Webhooks so. Gemeint ist die umgekehrte Richtung der Kommunikation.
• Event Stream: Ein fortlaufendes, geordnetes Protokoll von Ereignissen. Webhooks sind dagegen einzelne, unabhängige Zustellungen.

Außerdem finden Sie in Automatisierungstools oft einen Schritt namens „Webhook Trigger“. Das heißt nur, dass das Tool eine Empfangsadresse für Sie erzeugt. Die Logik bleibt gleich; lediglich hostet das Tool den Endpunkt statt Ihrer.

Wie halten Sie Webhook Abonnements schlank und wartbar?

Viele Anbieter bieten die Option „alle Ereignisse“. Das wirkt zunächst praktisch, macht in der Praxis aber Ärger. Ihr Empfänger erhält, prüft und speichert dann Hunderte Ereignisse, die er nie nutzt.

Abonnieren Sie also nur die Ereignisse, die Ihr Ablauf wirklich braucht. Für eine Abo Website genügen oft Zahlung erfolgreich, Zahlung fehlgeschlagen, Abo gekündigt und Erstattung. Mit neuen Funktionen erweitern Sie die Liste dann gezielt.

Getrennte Endpunkte für getrennte Zwecke erleichtern zudem die Wartung. Zahlungsereignisse gehen an eine Adresse, CRM Ereignisse an eine andere. Dann beeinflusst ein Fehler auf einer Seite die andere nicht, und die Auswertung der Logs geht viel schneller.

Planen Sie außerdem für Veränderungen. Anbieter ergänzen mit der Zeit Felder und bringen neue API Versionen heraus. Ignoriert Ihr Code unbekannte Felder nicht, bricht er womöglich eines Tages ohne Vorwarnung. Ändern sich Domain oder Server, aktualisieren Sie den Endpunkt im Dashboard des Anbieters. Geben Sie jedem Webhook einen Verantwortlichen, eine Monitoring Ansicht und einen Prüftermin.

Was ist ein Webhook Check für Ihr Unternehmen?

Wir haben geklärt, was ist ein Webhook, wie er funktioniert und wo die Risiken liegen. Jetzt fassen wir die Fragen zusammen, die Sie vor jedem Livegang stellen sollten.

• Welche Ereignisse brauchen wir wirklich, und gibt es unnötige Abonnements?
• Läuft der Endpunkt über HTTPS, und prüfen wir Signaturen über den rohen Inhalt?
• Liegt das Secret sicher außerhalb des Codes?
• Sortieren wir Duplikate über die Ereignis ID aus?
• Legen wir die Arbeit in eine Warteschlange und antworten schnell mit 2xx?
• Haben wir die Richtlinie des Anbieters für Wiederholungen in der Dokumentation gelesen?
• Gibt es einen regelmäßigen Abgleich für verpasste Ereignisse?
• Maskieren unsere Logs sensible Daten?

Zunächst wirkt jeder Punkt auf dem Papier einfach. Allerdings kann in verknüpften Systemen wie Zahlung, Lager und CRM ein einziger fehlender Punkt tagelange Datenabweichungen verursachen. Möchten Sie Ihre Integration von Anfang bis Ende planen, unterstützt Sie unser Team im Rahmen unserer individuellen Softwareentwicklung.

Was sollten Sie sich zu Webhooks merken?

Zusammengefasst ist ein Webhook eine Vereinbarung nach dem Motto „Melde dich, wenn es passiert“. Er ersetzt keine API, sondern ergänzt sie. Er ist schneller und sparsamer als Polling und für Meldungen zwischen Servern einfacher als WebSocket.

Diese Einfachheit bringt allerdings Verantwortung mit sich. Signaturen prüfen, Duplikate aussortieren, schnell antworten und verpasste Ereignisse auffangen: Das ist Ihre Aufgabe. Verankern Sie diese vier Gewohnheiten, dann läuft Ihr Webhook Setup über Jahre stabil.

Unser letzter Rat: Lesen Sie die Dokumentation jedes Anbieters einzeln. Namen der Header, Fristen für Wiederholungen und Signaturformate unterscheiden sich. Die allgemeine Antwort bleibt gleich, doch die Details ändern sich von Dienst zu Dienst.