Verify BigCommerce webhook signatures and protect against replays
domain: developer.bigcommerce.com · 6 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
When BigCommerce delivers a webhook, extract the `X-BC-Signature` header from the request.
Compute HMAC-SHA256 of the raw request body using your app's client secret as the key.
Compare the computed hash (hex-encoded) to the value in `X-BC-Signature` using a constant-time comparison function to prevent timing attacks.
Reject requests where the signature does not match with a 401 or 403 response before any business logic runs.
Record the timestamp from the webhook payload's `created_at` field and reject payloads older than a configurable window (e.g., 5 minutes) to mitigate replay attacks.
Respond with HTTP 200 immediately after signature validation; BigCommerce marks endpoints as inactive after repeated non-2xx responses and stops delivering events.
Known gotchas
The signature header is `X-BC-Signature` (signed with the app client secret) — not `X-Webhook-Signature` or any other name; using the wrong header name will cause all verifications to fail.
BigCommerce does not include a nonce in webhook deliveries, so timestamp-based replay protection is your only defense against replay attacks; implement and enforce a narrow acceptance window.
BigCommerce deactivates webhook destinations that consistently return non-2xx responses; monitor for deactivation events and re-enable via the Webhooks API if needed.
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?