A BigCommerce webhook inspector that shows you everything
BigCommerce webhooks are powerful and famously opaque. CommerceHook gives every delivery a home you can see: create a hosted endpoint, register it as your webhook destination, and read each event as it arrives.
How BigCommerce webhooks actually work
You register a webhook by calling the v3 hooks API with a scope (such
as store/order/created)
and an HTTPS destination URL. From then on BigCommerce sends a POST to
that URL each time the event happens. The payload is deliberately sparse:
the scope, your store identifier, and
a data object holding
little more than the resource type and ID. The expectation is that you
call the API back for the full resource.
Your handler must answer quickly with a success status. When it does not, BigCommerce retries on a backoff schedule, and a destination that keeps failing is eventually deactivated, at which point events silently stop. Much webhook debugging is really just discovering which of these things happened.
Why debugging them is painful
- Local development means tunnels. Tunnel URLs rotate, expire, and take your webhook registration down with them.
- A sparse payload plus a missing log line leaves you guessing whether the event never fired, fired and failed, or fired with different data than you expected.
- Retries and deactivation happen silently on the BigCommerce side; from your server's point of view the events just stop.
- console.log debugging shows you what your framework parsed, not what was actually delivered on the wire.
What a hosted inspector changes
CommerceHook is a stable HTTPS destination that always answers instantly,
so deliveries never fail while you are still building. Each event is
captured exactly as sent: the complete JSON payload in a collapsible
tree, every header
including x-bc-webhooks-event,
and the received time. When something misbehaves, you point the hook at
your endpoint, trigger the event in your store, and read the truth
instead of inferring it.
Commonly inspected BigCommerce webhook events
- store/order/created
- store/order/updated
- store/order/statusUpdated
- store/product/created
- store/product/updated
- store/product/inventory/updated
- store/customer/created
- store/customer/updated
- store/cart/created
- store/cart/converted
- store/shipment/created
- store/category/updated
Any scope BigCommerce can send, CommerceHook can receive; this list is the common starting set, not a limit.
Questions
How do I see what a BigCommerce webhook sent?
Register the webhook with a CommerceHook endpoint URL as its destination. Every delivery then appears in the inspector with its full payload, headers, and event type, seconds after BigCommerce sends it.
Why is my BigCommerce webhook not firing?
The usual causes are an unreachable or non-HTTPS destination, a handler that responds too slowly or with a non-2xx status, or the hook having been deactivated after repeated failures. Pointing the hook at a hosted inspector first tells you immediately whether BigCommerce is sending at all.
What data is in a BigCommerce webhook payload?
BigCommerce sends a compact JSON body: scope (the event type), store_id, producer, a hash, created_at, and a data object that usually contains just the resource type and ID. You then fetch the full resource from the API using that ID.
Does BigCommerce retry failed webhooks?
Yes. If your destination does not return a success response, BigCommerce retries on a backoff schedule, and hooks that keep failing are eventually deactivated. Watching deliveries in an inspector shows you exactly which attempts arrived and what they contained.
The Free plan takes about a minute to set up and needs no card.