Webhook Tester kostenlos online nutzen
Prüft Webhook-Payloads, Header und typische Integrationsfehler.
Philipp Bolender
Founder
Webhook Tester (GODmode)
Prüft Webhook-Payloads, Header und typische Integrationsfehler für 6 Provider (Generic, Stripe, GitHub, Shopify, Slack, n8n/Zapier). Berechnet die HMAC-Signatur live im Browser (Web Crypto API), validiert JSON, Content-Type, Payload-Größe, Idempotency und Timestamp- Drift, und generiert eine copy-fertige cURL-Zeile zum Replay gegen den echten Endpoint.
Berechnete Signatur
…
Checks
83/100- ✓Payload ist valides JSON
Payload lässt sich sauber parsen.
- ✓Content-Type passt zum Payload
Header: application/json
- ✓Signatur-Header X-Signature vorhanden
Wert: <wird berechnet>…
- ✗Signatur stimmt mit HMAC überein
Erwartet: …
- ✓Payload < 1 MB
51 Bytes – die meisten Provider und Edge-Runtimes limitieren bei 1 MB.
- ✓Eindeutige Event-/Delivery-ID vorhanden
Duplikate lassen sich auf Empfänger-Seite abfangen.
Replay gegen echten Endpoint
cURL zum Replay
curl -X POST 'https://dein-endpoint.example.com/webhook' \
-H 'Content-Type: application/json' \
-H 'X-Signature: ' \
-d '{"event":"order.created","id":"o_123","total":49.9}'Webhook-Regel 2026
Jeder Webhook-Empfänger prüft drei Dinge, bevor er den Payload anfasst: gültige Signatur (HMAC), Timestamp im 5-Minuten-Fenster (Replay-Schutz) und eindeutige Event-ID (Idempotency). Fehlt eines davon, ist die Integration angreifbar – und Duplikate landen doppelt in der DB.Webhook debuggen – Vibecoding-Guide 2026
Webhooks sind das Rückgrat jeder modernen Integration – von Stripe-Zahlungen über GitHub-Deploys bis zu n8n-Flows. Bricht ein Webhook, liegt es in 90 % der Fälle an einem von fünf Bausteinen: Signatur, Content-Type, Payload-Größe, Timestamp oder Idempotency.
| Baustein | Zweck | Fehlerbild |
|---|---|---|
| HMAC-Signatur | Authentizität | 401 / gefälschte Events verarbeitet |
| Content-Type | Payload-Parsing | 400, Body kommt als String an |
| Timestamp | Replay-Schutz | Alte Events erneut ausführen |
| Event-ID | Idempotency | Doppelte DB-Einträge nach Retry |
| Payload-Größe | Runtime-Limit | 413, Edge-Function bricht ab |
| 200-Response | Ack an Provider | Provider retryt bis 24h lang |
FAQ
Was ist ein Webhook Tester?
Ein Webhook Tester prüft, ob ein eingehender Webhook-Request korrekt aufgebaut ist: Payload, Header, Signatur, Timestamp und Idempotency-ID. So lassen sich Integrationen mit Stripe, GitHub, Shopify oder n8n testen, ohne echte Events auslösen zu müssen.
Wie funktioniert HMAC-Signaturprüfung?
Der Sender berechnet aus Raw-Body und einem Shared Secret einen HMAC-SHA256 und schickt ihn im Header mit. Der Empfänger berechnet den gleichen Hash und vergleicht beide. Stimmen sie überein, ist der Request authentisch – manipulierte Payloads führen zu einem anderen Hash.
Warum brauche ich eine Idempotency-ID?
Provider wie Stripe wiederholen Webhooks bei 5xx-Antworten automatisch. Ohne eindeutige Event-ID landet derselbe Payload mehrfach in der Datenbank. Best Practice: ID beim ersten Eintreffen speichern und bei Duplikaten mit 200 antworten, ohne erneut zu verarbeiten.
Was ist Replay-Schutz?
Angreifer könnten einen abgefangenen Webhook später erneut senden. Deshalb enthalten signierte Webhooks (Stripe, Slack) einen Timestamp. Der Empfänger lehnt Requests ab, deren Timestamp mehr als 5 Minuten in Vergangenheit oder Zukunft liegt.
Was Webhook Tester prüft
Ein Zahlungsanbieter, ein Formular oder eine Automatisierung soll dich benachrichtigen — und du willst sehen, was tatsächlich ankommt, bevor du Logik darauf baust. Der Tester gibt dir eine Adresse und zeigt eingehende Requests vollständig an.
So läuft die Prüfung
- 1Test-Endpunkt erzeugen. Die generierte URL beim Anbieter als Webhook-Ziel eintragen.
- 2Ereignis auslösen. Nutze die Testfunktion des Anbieters oder erzeuge eine echte Testtransaktion.
- 3Payload untersuchen. Header und Body prüfen: Feldnamen, Datentypen und Signatur-Header notieren.
- 4Auf den echten Endpunkt umstellen. Erst danach implementieren — mit Signaturprüfung und schneller 2xx-Antwort.
Befund richtig einordnen
- Viele Anbieter erwarten eine Antwort innerhalb weniger Sekunden. Lange Verarbeitung gehört hinter eine Queue, nicht in den Handler.
- Wiederholte Zustellungen sind normal — dein Handler muss idempotent sein, sonst entstehen doppelte Buchungen.
- Der Signatur-Header ist der einzige Schutz gegen gefälschte Aufrufe; ohne Prüfung ist der Endpunkt offen.
Typische Zweifelsfälle
Warum kommt gar nichts an?
Meist falsche URL, nicht aktiviertes Ereignis oder der Anbieter erreicht keine lokale Adresse. Erst Erreichbarkeit prüfen, dann Konfiguration.
Wie teste ich Wiederholungen?
Antworte im Test bewusst mit 500 — die meisten Anbieter stellen dann nach eigenem Zeitplan erneut zu.
Nächste Prüfschritte
Bau dein eigenes AI SaaS – ohne Dev-Team, ohne Bullshit.
Mein Vibecoding-Playbook: wie du mit Lovable, Cursor & Co. in Wochen (nicht Jahren) ein profitables Micro-SaaS baust, launched und monetarisierst.