Delivery behaviour
Read from the vendor's own documentation, last checked 2026-08-06. Where the vendor states no number, this table carries none.
| Response budget | not published by the vendor Delivery is queued into Action Scheduler and driven by WP-Cron, so it leaves when a page is next loaded rather than when the event happens |
|---|---|
| Retry | not published by the vendor |
| Gives up | Webhook disabled after more than five consecutive delivery failures |
| Source | https://woocommerce.com/document/webhooks/ |
Signature
Verified against a working verifier proven by a test suite, not read from documentation. Last verified 2026-08-20.
| Algorithm | HMAC-SHA256 |
|---|---|
| Signed payload | raw body |
| Encoding | base64 |
| Header | x-wc-webhook-signature |
| Tolerance | none enforced |
Verify it
The raw request body, byte for byte, before any JSON parsing. Every scheme on this page breaks the moment a framework re-serializes the payload.
const crypto = require("node:crypto");
// base64(HMAC-SHA256(secret, raw body))
const expected = crypto
.createHmac("sha256", webhookSecret)
.update(rawBody)
.digest("base64");
const valid = crypto.timingSafeEqual(
Buffer.from(req.headers["x-wc-webhook-signature"]),
Buffer.from(expected),
);What bites
The webhook does not fire when the order happens. Delivery is queued into Action Scheduler, which runs on WP-Cron, which runs when somebody next loads a page — on a quiet store that is minutes of built-in delay before the first byte leaves.
More than five consecutive delivery failures disable the webhook outright, and a store owner rarely finds out until something downstream goes visibly stale.
Read more
AnyHook sits in front of endpoints that receive from WooCommerce: it answers inside the budget above, retries on its own schedule when your server is down, and keeps every event replayable. Change one URL, keep your code.