Webhooks

Webhooks sind ein Mechanismus für Echtzeit-Kommunikation zwischen Anwendungen. Statt dass eine Anwendung regelmäßig eine API abfragt (Polling), sendet der Server automatisch eine HTTP-Anfrage an eine vordefinierte URL, sobald ein bestimmtes Ereignis eintritt. Das spart Ressourcen und ermöglicht sofortige Reaktionen auf Ereignisse.

Typische Beispiele: Stripe sendet einen Webhook, wenn eine Zahlung erfolgreich war; GitHub benachrichtigt Ihr CI/CD-System bei jedem Push; Shopify informiert über neue Bestellungen. Der Empfänger definiert eine Endpoint-URL, an die der Webhook-Sender POST-Requests mit Event-Daten (meist JSON) schickt. Best Practice ist die Validierung eingehender Webhooks via Signatur (HMAC) zur Sicherheit.

Webhooks sind das Rückgrat moderner Event-Driven-Architekturen. Sie ermöglichen lose gekoppelte Systeme, die unabhängig skalieren können. Für E-Commerce bedeutet das: Bestellung eingeht → Webhook an Warenwirtschaft → automatische Lagerbestandsaktualisierung → Webhook an Versanddienstleister → Tracking-Link zurück. Alles in Echtzeit, ohne manuelle Schritte.

Beim Empfangen von Webhooks sind einige Robustheits- und Sicherheitsregeln entscheidend. Erstens die Signaturprüfung: Anbieter wie Stripe senden einen HMAC-Signatur-Header, den der Empfänger mit einem geheimen Schlüssel gegen den rohen Request-Body verrechnet - stimmt die Signatur nicht, wird die Anfrage verworfen. Ohne diese Prüfung könnte jeder gefälschte POST-Requests an den öffentlichen Endpoint schicken. Zweitens die Idempotenz: Da Sender bei ausbleibender Bestätigung erneut zustellen, kann derselbe Event mehrfach ankommen; der Empfänger muss anhand einer Event-ID eine Doppelverarbeitung verhindern, sonst wird etwa eine Bestellung doppelt angelegt.

Wichtig ist außerdem, den Webhook sofort mit HTTP 200 zu quittieren und die eigentliche Verarbeitung in einen Hintergrund-Job (Queue) auszulagern - dauert die Antwort zu lange, wertet der Sender das als Fehlschlag und wiederholt. Da Zustellreihenfolge und -garantie nicht sicher sind, sollte der Code nicht auf eine bestimmte Event-Abfolge vertrauen; dauerhaft fehlschlagende Events landen idealerweise in einer Dead-Letter-Queue. Zum lokalen Testen leitet man öffentliche Requests mit Tools wie ngrok oder der Stripe CLI an den Entwicklungsrechner weiter, während webhook.site Payloads inspiziert. Abzugrenzen sind Webhooks von WebSockets (dauerhafte, bidirektionale Verbindung für Live-Daten im Browser) und vom ressourcenhungrigen Polling - Webhooks sind die effizienteste Wahl für serverseitige, ereignisgesteuerte Server-zu-Server-Kommunikation.