Ein Webhook ist eine automatische HTTP-Benachrichtigung, die ein System an ein anderes sendet, sobald ein bestimmtes Ereignis eintritt – etwa eine neue Zahlung, eine Kündigung oder ein Tarifwechsel. Statt dass ein Empfängersystem wiederholt nachfragen muss, ob sich etwas geändert hat, informiert der Absender es aktiv und in Echtzeit über relevante Ereignisse.
Der Unterschied zu klassischen API-Abfragen
Ohne Webhooks müsste ein System, das über Änderungen in einem anderen System informiert sein möchte, in regelmäßigen Abständen aktiv nachfragen – ein Verfahren, das als Polling bezeichnet wird. Polling verursacht unnötige Last, da die meisten Abfragen ergebnislos bleiben, und führt zwangsläufig zu Verzögerungen zwischen dem tatsächlichen Ereignis und dessen Erkennung. Webhooks kehren dieses Prinzip um: Statt zu fragen „Hat sich etwas geändert?", informiert das sendende System das Zielsystem aktiv, sobald tatsächlich ein relevantes Ereignis eintritt.
Typische Webhook-Events im Subscription-Geschäft
- Neue Zahlung eingegangen: Informiert etwa ein CRM-System, dass ein Kunde erfolgreich bezahlt hat.
- Zahlung fehlgeschlagen: Löst häufig automatisch einen Prozess im Dunning Management aus.
- Vertragskündigung: Kann eine Zugangssperrung in einem angebundenen Produktsystem auslösen.
- Tarifwechsel: Aktualisiert beispielsweise Nutzungslimits in einer angebundenen Anwendung.
- Neuer Kunde angelegt: Erstellt automatisch einen entsprechenden Kontakt in einem CRM- oder Marketing-Tool.
Der technische Aufbau eines Webhooks
Ein Webhook besteht im Kern aus einer vom Empfänger bereitgestellten URL (dem sogenannten Endpoint) sowie einem strukturierten Datenpaket (Payload), das die relevanten Informationen zum eingetretenen Ereignis enthält – meist im JSON-Format. Tritt das definierte Ereignis ein, sendet das Quellsystem eine HTTP-Anfrage mit diesem Payload an die hinterlegte URL. Das Empfängersystem verarbeitet die Daten daraufhin unmittelbar, ohne selbst aktiv nachfragen zu müssen.
Sicherheit: Warum Signaturen wichtig sind
Da ein Webhook-Endpoint öffentlich erreichbar sein muss, um Anfragen empfangen zu können, besteht grundsätzlich das Risiko, dass auch unbefugte Dritte gefälschte Anfragen an diese URL senden. Seriöse Systeme signieren deshalb jede Webhook-Anfrage kryptographisch, sodass das Empfängersystem die Echtheit und Unverändertheit der Nachricht anhand dieser Signatur überprüfen kann, bevor es die enthaltenen Daten verarbeitet.
⚠️ Webhook-Signaturen immer prüfen
Wer einen Webhook-Endpoint implementiert, sollte die mitgelieferte Signatur jeder eingehenden Anfrage konsequent verifizieren. Ohne diese Prüfung könnte ein Angreifer gefälschte Ereignisse vortäuschen – etwa eine nicht tatsächlich erfolgte Zahlung – und dadurch Geschäftslogik im Empfängersystem manipulieren.
Umgang mit fehlgeschlagenen Zustellungen
Ist ein Empfänger-Endpoint vorübergehend nicht erreichbar – etwa wegen Wartungsarbeiten oder eines kurzzeitigen Ausfalls – muss das sendende System die Zustellung erneut versuchen, statt das Ereignis stillschweigend zu verwerfen. Robuste Webhook-Implementierungen nutzen dafür eine gestaffelte Retry-Logik mit zunehmenden Zeitabständen zwischen den Versuchen sowie eine Protokollierung fehlgeschlagener Zustellungen zur nachträglichen manuellen Prüfung.
Idempotenz: Warum doppelte Zustellungen kein Problem sein sollten
Aufgrund der Retry-Logik kann es vorkommen, dass ein Webhook-Ereignis mehrfach zugestellt wird – etwa wenn die Bestätigung des ersten Zustellversuchs verloren geht, obwohl die Verarbeitung eigentlich erfolgreich war. Gut konzipierte Empfängersysteme sind deshalb idempotent aufgebaut: Sie erkennen anhand einer im Payload enthaltenen eindeutigen Ereignis-ID, ob ein Ereignis bereits verarbeitet wurde, und verarbeiten es im Zweifel kein zweites Mal, um doppelte Buchungen oder Benachrichtigungen zu vermeiden.
Webhooks versus REST-API: Zwei komplementäre Ansätze
Webhooks und eine REST-API schließen sich nicht gegenseitig aus, sondern ergänzen sich: Die REST-API eignet sich für gezielte, vom Empfängersystem initiierte Abfragen bestimmter Daten, während Webhooks proaktiv über Ereignisse informieren, ohne dass das Empfängersystem aktiv fragen muss. In der Praxis kombinieren viele Integrationen beide Ansätze – der Webhook informiert über ein Ereignis, die anschließende API-Abfrage lädt bei Bedarf weitere Detaildaten nach.
Praktischer Nutzen für Systemintegrationen
Webhooks sind die technische Grundlage vieler NoCode-Integrationen, bei denen Ereignisse in einem System automatisch Aktionen in einem völlig anderen Tool auslösen – etwa das automatische Anlegen eines Kontakts in einem CRM, sobald in Fakturia ein neuer Vertrag entsteht. Ohne Webhooks müssten solche Verknüpfungen über regelmäßiges, ineffizientes Polling realisiert werden, was sowohl höhere Systemlast als auch spürbare Verzögerungen bei der Datenübertragung zur Folge hätte.
Fazit
Webhooks ermöglichen es Systemen, sich in Echtzeit gegenseitig über relevante Ereignisse zu informieren, ohne auf ineffizientes, wiederholtes Nachfragen angewiesen zu sein. Ihre korrekte Absicherung durch Signaturprüfung sowie eine robuste Retry-Logik bei vorübergehenden Zustellungsproblemen sind entscheidend für eine zuverlässige und sichere Systemintegration.