Testen von Webhooks und HMAC-Signaturprüfung

Webhook-Empfänger sind öffentliche Endpunkte, die Daten von externen Quellen verarbeiten. Dadurch ist die Signaturprüfung die einzige Sicherheitsmaßnahme zwischen Ihnen und jedem, der Ihre URL kennt. Die Webhooks-API signiert jede Zustellung mit einem HMAC und führt ein Zustellungsprotokoll, das Sie einsehen und wiedergeben können. So können Sie die Prüffunktion testen, anstatt ihr blind zu vertrauen.

Echte Endpunkte aus dem Katalog – jede der oben genannten Anfragen wird bedient, und jeder angezeigte Statuscode ist ein Statuscode, den dieser Endpunkt tatsächlich zurückgibt.

Wie man es übt

Registrieren Sie ein Abonnement, lösen Sie ein Ereignis aus und prüfen Sie die Signatur mit dem gemeinsamen Geheimnis vor der Verarbeitung.
Ändern Sie ein Byte der Nutzdaten und prüfen Sie, dass die Signaturprüfung fehlschlägt.
Wiederholen Sie eine gespeicherte Zustellung und prüfen Sie, dass der Empfänger dasselbe Ereignis nicht doppelt verarbeitet.
Prüfen Sie eine Vergleichsmethode mit konstanter Laufzeit. Gewöhnliche Zeichenkettenvergleiche können Timing-Informationen preisgeben.
Prüfen Sie im Zustellungsprotokoll die tatsächlich angekommenen Header, statt sie vorauszusetzen.

APIs, um es auszuprobieren

Webhooks-API — Register callbacks, trigger events, inspect & replay deliveries. (7 endpoints)
Fehlerinjektions-API — Latency, status codes, malformed payloads & flaky responses. (5 endpoints)

Betroffene Statuscodes

Andere Techniken

API-Paginierung testen — Practise page-number and cursor pagination, and the edge cases that break clients: the last partial page, an out-of-range page, and a total count that disagrees with what you collected.
API-Ratenbegrenzung testen — Trigger a real 429 with Retry-After and X-RateLimit headers, and verify your client backs off instead of retrying straight into the limit.
Idempotenz-Schlüsseltest— Send the same write twice with an Idempotency-Key and confirm the operation happens once — the mechanism that stops a network retry becoming a duplicate charge.
ETag- und If-Match-Test— Provoke a 412 Precondition Failed by writing with a stale ETag — the check that stops two clients silently overwriting each other.
OAuth- und JWT-Tests — Run real client-credentials, authorization-code and device-code flows, then test what your client does when the token expires mid-session.
Negativer Test — Provoke 400, 401, 403, 404, 409, 418, 422, 429, 500 and 503 deliberately, and check your client handles each one differently.
Asynchrone Jobtests— Start a long-running job, follow the 202 and its Location header, and poll to completion — including the failure and timeout paths.

Einstiegsanleitung · Alle 39 Mock-REST-APIs

Zuletzt aktualisiert 16. Oktober 2026