Die meisten Empfänger verarbeiten Webhooks direkt in der Antwort. Damit beginnt genau das Problem, das sie vermeiden wollen.
Wer die eigentliche Arbeit in die Antwortfrist legt, riskiert Timeouts und doppelte Zustellungen.
🧱 Grundlagen – Bestätigung und Verarbeitung sind zwei Schritte. Ein Webhook-Endpunkt ist ein HTTP-Server: Erst mit einem 2xx-Status gilt die Zustellung beim Sender als bestätigt. Sendet der Empfänger keine rechtzeitige Antwort, wiederholt der Sender die Lieferung, meist immer wieder.
⚙️ Praxis – 200 zurückgeben, bevor die Arbeit beginnt. Dafür ist ein fester Ablauf bewährt: Zeitfenster prüfen, Signatur mit dem gemeinsamen Geheimnis verifizieren, Ereignis-ID gegen einen Duplikatspeicher prüfen, Rohdaten in eine Warteschlange legen, dann sofort mit 200 antworten. Die Ausführung läuft als Hintergrundjob, unabhängig vom Zeitdruck der Antwort. Ein Fehlerkonzept für die Warteschlange ist Pflicht: Nicht zustellbare Jobs wiederholen oder in eine Fehlerschleife legen, damit kein stiller Datenverlust entsteht.
🎯 Experte – At-least-once erfordert Idempotenz statt Schnelligkeit. Webhook-Sender liefern in der Regel mindestens einmal, auch wenn der Empfänger bereits verarbeitet hat. Der sichere Schutz ist eine gespeicherte, eindeutige Ereignis-ID, die erneut eintreffende Nachrichten überspringt. Zusätzlich gilt: Die Reihenfolge von Webhooks ist nicht garantiert, die Verarbeitung darf also nie annehmen, dass Ereignis A vor Ereignis B eintrifft.
⚠️ Stolperfalle – Erst Zeitfenster und Signatur prüfen, dann erst den Body parsen. Der Body muss dafür byteweise unverändert vorliegen, sonst schlägt die Signaturprüfung fehl.
Webhook-Empfang heißt nicht schnell verarbeiten, sondern schnell bestätigen und idempotent verarbeiten.
📌 2xx sofort · Verarbeitung entkoppeln · Idempotenz
#Webhooks #Automatisierung #Integration #api
Wer die eigentliche Arbeit in die Antwortfrist legt, riskiert Timeouts und doppelte Zustellungen.
🧱 Grundlagen – Bestätigung und Verarbeitung sind zwei Schritte. Ein Webhook-Endpunkt ist ein HTTP-Server: Erst mit einem 2xx-Status gilt die Zustellung beim Sender als bestätigt. Sendet der Empfänger keine rechtzeitige Antwort, wiederholt der Sender die Lieferung, meist immer wieder.
⚙️ Praxis – 200 zurückgeben, bevor die Arbeit beginnt. Dafür ist ein fester Ablauf bewährt: Zeitfenster prüfen, Signatur mit dem gemeinsamen Geheimnis verifizieren, Ereignis-ID gegen einen Duplikatspeicher prüfen, Rohdaten in eine Warteschlange legen, dann sofort mit 200 antworten. Die Ausführung läuft als Hintergrundjob, unabhängig vom Zeitdruck der Antwort. Ein Fehlerkonzept für die Warteschlange ist Pflicht: Nicht zustellbare Jobs wiederholen oder in eine Fehlerschleife legen, damit kein stiller Datenverlust entsteht.
🎯 Experte – At-least-once erfordert Idempotenz statt Schnelligkeit. Webhook-Sender liefern in der Regel mindestens einmal, auch wenn der Empfänger bereits verarbeitet hat. Der sichere Schutz ist eine gespeicherte, eindeutige Ereignis-ID, die erneut eintreffende Nachrichten überspringt. Zusätzlich gilt: Die Reihenfolge von Webhooks ist nicht garantiert, die Verarbeitung darf also nie annehmen, dass Ereignis A vor Ereignis B eintrifft.
⚠️ Stolperfalle – Erst Zeitfenster und Signatur prüfen, dann erst den Body parsen. Der Body muss dafür byteweise unverändert vorliegen, sonst schlägt die Signaturprüfung fehl.
Webhook-Empfang heißt nicht schnell verarbeiten, sondern schnell bestätigen und idempotent verarbeiten.
📌 2xx sofort · Verarbeitung entkoppeln · Idempotenz
#Webhooks #Automatisierung #Integration #api
5 Tage vor
