Wer mehrere Softwaresysteme miteinander verbindet, steht früher oder später vor einer grundsätzlichen Frage: Wie erfahren die angebundenen Systeme, dass in einem anderen System etwas passiert ist? Es gibt im Wesentlichen zwei Ansätze. Beim Polling fragt ein System in regelmäßigen Abständen beim anderen nach – „Gibt es Neuigkeiten?" Beim Webhook benachrichtigt das Quellsystem seine Empfänger aktiv, sobald ein Ereignis eintritt – „Etwas ist passiert, hier sind die Details." Im Kontext von Subscription-Management ist der Unterschied zwischen diesen Ansätzen erheblich: in Echtzeit, in Effizienz und in der Verlässlichkeit der Prozesskette.

Was ist ein Webhook technisch gesehen?

Ein Webhook ist im Kern eine HTTP-Anfrage, die ein System automatisch an eine vordefinierte URL sendet, sobald ein bestimmtes Ereignis eintritt. Das Zielsystem – etwa ein CRM, ein ERP, ein E-Mail-Marketing-Tool oder eine selbst entwickelte Anwendung – empfängt diese Anfrage, verarbeitet die enthaltenen Daten und löst seinerseits entsprechende Aktionen aus. Die Nutzlast des Webhooks ist üblicherweise ein JSON-Objekt, das alle relevanten Informationen zum Ereignis enthält: Ereignistyp, Zeitstempel, betroffene Entitäten und ihre aktuellen Zustandsdaten.

Aus Entwicklersicht ist ein Webhook damit das Gegenteil einer API-Abfrage: Statt dass das eigene System aktiv Daten holt (Pull), werden Daten aktiv geliefert (Push). Das reduziert den Netzwerkverkehr, eliminiert Latenz und stellt sicher, dass keine Ereignisse übersehen werden – vorausgesetzt, das Zielsystem ist erreichbar und quittiert den Empfang korrekt.

Typische Webhook-Ereignisse im Subscription-Kontext

Die Bandbreite sinnvoller Webhook-Ereignisse im Subscription-Management ist groß. Fakturia informiert Kundensysteme über alle wesentlichen Zustandsänderungen in Echtzeit. Zu den häufigsten Anwendungsfällen gehören dabei folgende Ereignisse.

Neuer Vertrag angelegt: Das CRM-System legt automatisch einen neuen Kundendatensatz an, der Onboarding-E-Mail-Flow wird gestartet, der zuständige Account Manager erhält eine Benachrichtigung. All das passiert in Sekunden, ohne dass jemand manuell eingreifen muss.

Zahlung erfolgreich: Das Buchhaltungssystem erhält die Buchungsinformation, der Zugriff auf ein gesperrtes Feature wird entsperrt, eine Dankes-E-Mail wird ausgelöst. Auch hier vollautomatisch und ohne Verzögerung.

Zahlung fehlgeschlagen: Das Support-System erhält eine Aufgabe, dem Kunden wird automatisch eine Zahlungserinnerung zugestellt, das Dunning-Management wird gestartet. Der Webhook sorgt dafür, dass alle beteiligten Systeme synchron reagieren.

Kündigung eingegangen: Das CRM markiert den Kunden als gefährdet, eine Win-back-Kampagne wird geplant, das Customer-Success-Team wird informiert. Auch Vertragsenddatum und eventuell anteilige Rückerstattungen können direkt verarbeitet werden.

Zuverlässigkeit: Retry-Logik und Quittierung

Ein häufig unterschätzter Aspekt bei der Arbeit mit Webhooks ist die Frage der Zuverlässigkeit. Was passiert, wenn das Zielsystem zum Zeitpunkt des Ereignisses nicht erreichbar ist – etwa wegen eines Deployments, eines kurzzeitigen Ausfalls oder einer Netzwerkunterbrechung? Ein professionelles Webhook-System antwortet darauf mit einer Retry-Logik: Der Webhook wird nach einem definierten Muster erneut gesendet, bis das Zielsystem mit einem HTTP-200-Statuscode quittiert oder eine maximale Anzahl von Versuchen erreicht ist.

Auf Empfängerseite ist es wichtig, Webhooks idempotent zu verarbeiten – das heißt, eine doppelte Zustellung desselben Ereignisses darf nicht zu doppelten Aktionen führen. Üblich ist dabei die Prüfung einer eindeutigen Ereignis-ID: Wurde dieses Ereignis bereits verarbeitet, wird der Webhook still ignoriert.

Webhooks vs. REST-API: Das richtige Werkzeug für den richtigen Zweck

Webhooks und REST-API ergänzen sich im Subscription-Management ideal. Die API ist das richtige Werkzeug für gezielte, synchrone Abfragen: „Gib mir alle aktiven Verträge dieses Kunden." Webhooks sind das richtige Werkzeug für ereignisgesteuerte, asynchrone Reaktionen: „Sag mir sofort Bescheid, wenn sich an einem Vertrag etwas ändert." Wer beide Mechanismen kombiniert, baut eine Systemlandschaft, die weder auf Polling angewiesen ist noch auf manuelle Datensynchronisation – und damit die Voraussetzungen für einen vollständig automatisierten Order-to-Cash-Prozess schafft.