Anfrage authentifizieren und unverändert erfassen
Prüfen Sie die vom Anbieter dokumentierte Signatur gegen den rohen Request-Body, bevor JSON normalisiert oder Felder verändert werden. Zeitstempel und Replay-Schutz begrenzen die Wiederverwendung abgefangener Nachrichten.
Speichern Sie Ereignis-ID, Typ, Empfangszeit, Quellsystem und eine sichere Referenz auf den Inhalt. Personenbezogene oder sensible Daten werden nur so lange und so vollständig gespeichert, wie Fehleranalyse und Fachprozess es erfordern.
Schnell bestätigen und asynchron verarbeiten
Der HTTP-Endpunkt validiert, persistiert und legt das Ereignis in eine Warteschlange. Danach antwortet er innerhalb des Anbieter-Zeitfensters. Langsame ERP-Aufrufe, E-Mails oder PDF-Erzeugung gehören in Worker, nicht in den Empfangspfad.
Kann das Ereignis nicht sicher gespeichert werden, darf kein erfolgreicher Status zurückgegeben werden. Nur so erhält der Anbieter die Chance auf eine Wiederholung.
Jede fachliche Aktion idempotent gestalten
Idempotenz bedeutet, dass dieselbe Nachricht mehrfach verarbeitet werden kann, ohne das Ergebnis mehrfach zu erzeugen. Eine eindeutige Ereignis-ID oder fachliche Kombination wird mit dem Verarbeitungsergebnis gespeichert. Vor Rechnung, Gutschrift oder Bestandsbuchung prüft der Worker diese Sperre atomar.
Ein einfaches „bereits gesehen“ vor Beginn reicht nicht: Stürzt der Prozess danach ab, bleibt die Aktion möglicherweise unvollständig. Speichern Sie Status, Teilschritte und externe Referenzen transaktional oder über einen klaren Zustandsautomaten.
- Eindeutiger Idempotenzschlüssel
- Status neu, in Bearbeitung, abgeschlossen oder fehlgeschlagen
- Externe IDs für erzeugte Objekte
- Atomare Sperre gegen parallele Worker
- Sicher wiederholbare Teilschritte
Wiederholungen und Reihenfolge kontrollieren
Vorübergehende Fehler werden mit wachsendem Abstand und Zufallsanteil wiederholt. Dauerhafte fachliche Fehler, etwa eine ungültige Zuordnung, benötigen keine endlose Wiederholung. Nach einer Grenze wandert das Ereignis in eine Dead-Letter-Queue.
Verlassen Sie sich nicht blind auf Lieferreihenfolge. Lesen Sie bei wichtigen Statuswechseln den aktuellen Zustand aus dem Quellsystem oder vergleichen Sie Versions- und Ereigniszeiten. Eine verspätete Meldung darf keinen neueren Zustand überschreiben.
Betrieb und manuelle Wiederaufnahme ermöglichen
Dashboards zeigen Eingangsrate, Latenz, Fehlerquote, Retry-Alter und Größe der Dead-Letter-Queue. Alarme richten sich nach Geschäftsauswirkung: Ein einzelner Produktfehler ist anders zu behandeln als ein kompletter Ausfall aller Zahlungsereignisse.
Ein Admin-Werkzeug zeigt bereinigte Ereignisdaten, Fehlergrund und bisherigen Verlauf. Berechtigte Mitarbeitende können nach Korrektur gezielt erneut verarbeiten, ohne Shell-Zugriff oder manuelle Datenbankänderung.
Kurz beantwortet
Häufige Fragen
Warum kommen Webhooks doppelt an?
Anbieter wiederholen Ereignisse, wenn eine Antwort fehlt oder unklar ist. Netzwerke können außerdem Antworten verlieren. Empfänger müssen daher mit Dubletten rechnen.
Was ist eine Dead-Letter-Queue?
Sie sammelt Nachrichten, die nach mehreren Versuchen nicht verarbeitet werden konnten, damit sie analysiert und gezielt erneut gestartet werden können.
Soll ein Webhook sofort alle Folgeaktionen ausführen?
Meist nein. Der Endpunkt sollte schnell validieren und speichern; zeitaufwendige oder fehleranfällige Arbeit läuft anschließend asynchron.
