Testing webhooks and HMAC signature verification

Webhook receivers are public endpoints that act on data from outside, which makes signature verification the only thing between you and anyone who knows your URL. The Webhooks API signs every delivery with an HMAC and keeps a delivery log you can inspect and replay, so you can test the verifier rather than trusting it.

Real endpoints from the catalog — every request above is served, and every status code shown is one that endpoint actually returns.

How to practise it

Register a subscription, trigger an event, and verify the signature against the shared secret before doing anything with the body.
Change one byte of the payload and confirm verification fails.
Replay a stored delivery and check your receiver is idempotent instead of processing it twice.
Check that your comparison is constant-time — a naive string equality leaks the signature a byte at a time.
Inspect the delivery log to see exactly which headers arrived, rather than the ones you assumed would.

APIs to try it on

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

Status codes involved

Other techniques

Pagination testing — 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.
Rate limit testing — Trigger a real 429 with Retry-After and X-RateLimit headers, and verify your client backs off instead of retrying straight into the limit.
Idempotency key testing — 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 and If-Match testing — Provoke a 412 Precondition Failed by writing with a stale ETag — the check that stops two clients silently overwriting each other.
OAuth and JWT testing — Run real client-credentials, authorization-code and device-code flows, then test what your client does when the token expires mid-session.
Negative testing — Provoke 400, 401, 403, 404, 409, 418, 422, 429, 500 and 503 deliberately, and check your client handles each one differently.
Async job testing — Start a long-running job, follow the 202 and its Location header, and poll to completion — including the failure and timeout paths.

Getting started guide · All 39 mock REST APIs

Last updated 6 September 2026