Webhook signature fails after retry: check raw body, timestamp, and idempotency first

When a webhook signature fails after retry, the safest first step is to separate byte verification, timestamp tolerance, and duplicate handling before touching business logic.

Start with the raw body. Many frameworks parse JSON before the handler sees it, and a re-stringified body may not match the provider signature. Check whether the verifier receives the exact bytes the provider signed. Record body length, content type, signature header, timestamp header, and whether any middleware runs before verification. If a proxy or serverless layer buffers the request, note that too.

Next check timestamp tolerance. A retry may arrive later than the first attempt, and local clocks or queue delays can make a valid delivery look expired. The timestamp rule should be compared with provider docs and server time. Do not widen the tolerance blindly; first confirm whether the failure is a stale timestamp or a body mismatch.

Then check idempotency. A retry can be valid and still cause duplicate side effects if the handler does not record event ids. If the first delivery partially succeeded, the second delivery may hit a different branch and look like a signature or provider problem. Store the event id, processing state, and final result separately from the business action.

A useful reproduction uses one redacted provider event, one local verifier test, and one receiver log line that shows body length and timestamp result. That is enough to decide whether the next fix belongs in parsing, clock handling, or idempotency.

This order avoids the expensive mistake: rotating secrets, rewriting handlers, and blaming retries before proving whether the receiver verified the same request the provider sent.

Webhook signature fails after retry: check raw body, timestamp, and idempotency first

// COMMENTS

ON THIS PAGE