WooCommerce ships native webhook support under WooCommerce's Advanced settings: pick a topic like order created, product updated, or customer created, point it at a URL, and WooCommerce POSTs the event there the moment it happens, signed so you can verify it's genuine. That's the whole feature. What happens after your server receives that POST, updating a second system, triggering a notification, retrying if it fails, is work nobody builds unless someone sits down and builds it.
Each webhook is set up against a specific topic (`order.created`, `order.updated`, `product.created`, `customer.updated`, and similar), delivered as a POST request carrying the relevant object as JSON. WooCommerce signs the payload with a secret you set when creating the webhook, included as an `X-WC-Webhook-Signature` header, so your endpoint can confirm the request actually came from your store and wasn't forged.
A genuinely common, separate case is the Stripe gateway for WooCommerce, which registers its own webhook endpoint directly with Stripe rather than going through WooCommerce's webhook system at all. That's what catches events a checkout page can't see on its own: a card that clears 3D Secure a minute later, a subscription renewal that succeeds or fails overnight, a dispute opened days after the sale. Getting the Stripe webhook secret and endpoint set up correctly on both sides is where a lot of 'why didn't this order update' problems come from.
WooCommerce doesn't automatically retry a failed delivery forever, and a webhook that fails silently, because your receiving server was down for five minutes, because a deploy was mid-flight, looks identical to an order that never fired an event at all unless you're logging deliveries somewhere and checking.
Getting the POST request is the easy part. Verifying the signature, parsing the payload correctly for that specific topic, and deciding what to actually do with it (update a CRM record, kick off a fulfillment step, flag a failed Stripe renewal for a person) is a separate piece of logic for every topic you subscribe to, and it has to handle the event arriving twice, arriving out of order, or not arriving at all.
Most businesses end up needing both a webhook and a periodic API check in parallel: the webhook for speed, a scheduled sync as the backstop that catches anything a dropped delivery missed. Running only the webhook and trusting it completely is how a quiet gap shows up months later when someone notices an order that never made it into the accounting system.
A subscription payment that fails overnight through Stripe's webhook triggers an internal flag and a customer email automatically, instead of someone finding out a week later when the customer asks why their access stopped.
Every delivery gets logged, and a scheduled check against the API catches anything a dropped or failed webhook missed, so a five-minute server outage doesn't quietly turn into a missing order.
A renewal failure, a new order, a cancelled subscription: tell us which event you're currently catching by checking a dashboard, and we'll scope what it'd take to catch it automatically instead.
A dashboard someone checks is a polling system with a person doing the polling. WooCommerce's webhooks, and Stripe's separately, exist so nobody has to be that person, but only once something's actually listening on the other end. We build that listener, and WooCommerce events are just the example here: n-frames does this for whatever tool in your stack already fires an event that nobody's catching yet.
Let's talk →Under WooCommerce's Advanced settings, add a webhook, choose a topic like order created or product updated, and give it a delivery URL and a secret. WooCommerce starts posting that event's JSON payload to the URL the moment it happens.
Usually one of three things: the topic doesn't match what you expected (product updated and product stock changed are different events), the webhook status got switched to disabled or paused after repeated delivery failures, or the receiving endpoint is returning an error that WooCommerce is logging but nobody's checking.
A webhook pushes an event to you the instant it happens. Polling means your system asks the API on a schedule whether anything changed. Webhooks are faster and lighter on both sides, but they can fail silently, which is why most reliable integrations use a webhook for speed and a scheduled API check as a backstop.
It's generated when you set up the webhook endpoint in your Stripe dashboard, then entered into the WooCommerce Stripe gateway's settings so WooCommerce can verify the events are genuinely from Stripe. It's separate from any secret used by WooCommerce's own native webhook system.