For each IDV provider, retrieve the shared webhook secret from the provider's dashboard and store it securely in your secrets manager, never in source code
In your webhook handler, read the raw request body as bytes before any JSON parsing, since signature computation uses the exact raw payload
Compute the expected signature using the algorithm specified by each provider (commonly HMAC-SHA256 over the raw body using the shared secret)
Compare the computed signature against the value in the provider-specific signature header using a constant-time comparison function to prevent timing attacks
Reject the request with a 401 response immediately if the signature does not match, without processing any payload data
Implement a replay attack defense by checking a timestamp field in the payload against the current time and rejecting events that are too old (typically more than five minutes)
Known gotchas
Parsing the JSON body before extracting the raw bytes for signature computation is a common bug that causes constant signature mismatches; always capture the raw bytes first
Standard string equality comparison is vulnerable to timing attacks on the signature; use a cryptographic constant-time comparison function provided by your language's standard library
Webhook secrets must be rotated on a schedule or immediately on suspected compromise; build a rotation mechanism that accepts both old and new secrets during a brief transition window
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp