BigCommerce Webhooks: Send Store Events to Sazabi

Webhook facts checked on the platform’s docs on Nov 8, 2026.

BigCommerce webhooks tell you when something changes in a store: an order is created, a shipment is added, a cart is abandoned. Sending them to Sazabi keeps a searchable record of every notification, which helps when an order sync or inventory feed drifts.

What BigCommerce sends

Every webhook is subscribed to a scope, written as store/<resource>/<event>. Examples from the event reference include store/order/created, store/order/updated, store/order/statusUpdated, store/cart/created, store/cart/abandoned, store/customer/created, store/shipment/created and store/product/inventory/updated. A wildcard such as store/order/* covers a whole resource.

When a scope fires, BigCommerce POSTs a light payload. It identifies the event and the resource but does not include the full order or product. The data object holds the resource type and id, and for store/order/statusUpdated it holds only the order ID. You then call the API for the details if you need them.

Why send BigCommerce webhooks to Sazabi

A light payload is cheap to store and still useful. A run of store/order/created records tells you what BigCommerce announced, and the order ID in each one lets you search your own logs for what your fulfillment service did with it.

Sazabi's Webhook Events source stores each JSON payload as a log record with the fields under webhook.* attributes. A path suffix such as /bigcommerce is saved as webhook.path. If you run several stores, add a different suffix per store so you can tell them apart.

Create a BigCommerce webhook

BigCommerce documents webhook creation through its API. Copy your intake URL from the Webhook Events source and keep it private, then send a request to the Create a webhook endpoint:

POST https://api.bigcommerce.com/stores/<store_hash>/v3/hooks
X-Auth-Token: <your API token>
Content-Type: application/json
Accept: application/json

{
  "scope": "store/order/created",
  "destination": "<your intake URL>/bigcommerce",
  "is_active": true,
  "headers": {}
}

Two requirements from the docs matter here. The destination must be served on port 443, because custom ports are not supported. A new webhook can take up to a minute to start working. To test, create or edit an order in a development store and look for the record in Sazabi.

Create one hook per scope, or use a wildcard scope to cover a resource. Webhooks created with one API token are not visible when you list hooks with a different token, so keep a note of which token made them.

Example BigCommerce payload

This example follows the callback payload in the BigCommerce docs for store/order/created. The hash and IDs are illustrative.

{
  "scope": "store/order/created",
  "store_id": "1025646",
  "data": {
    "type": "order",
    "id": 250
  },
  "hash": "dd70c0976e06b67aaf671e73f49dcb79230ebf9d",
  "created_at": 1561479335,
  "producer": "stores/abcde"
}

Search for the scope value or the order ID to find it. If a hook fires twice for the same event, BigCommerce says both request bodies share the same hash, which makes duplicates easy to spot.

What to watch for

• The delivery exception hook. BigCommerce can send store/hook/deliveryException to a different destination when regular hooks fail. Error 90001 means a retry is coming, 90002 means attempts are exhausted and the hook will be disabled, and 90003 means the domain was temporarily blocked. The docs require a destination that differs from all other hook destinations.
• Blocklisting. If the success ratio in a two minute window drops below 90 percent, the destination is blocklisted for three minutes and some events go to the retry queue. The ratio is not calculated until 100 requests are sent in the window.
• Retry schedule. Retries run after 60, 180, 300, 600, 900, 1800, 3600, 7200, 21600, 50400 and 86400 seconds. After that, about 48 hours from the first attempt, BigCommerce emails the app contact and sets is_active to false.
• Inactivity. The docs say a subscription is deactivated after 90 days of inactivity. Check is_active with the Get a webhook endpoint after a quiet period.
• Signing. BigCommerce follows Standard Webhooks for verification and uses a timestamp against replay attacks.

For comparison with other commerce and payments platforms, read the Square and PayPal guides. The integrations overview lists everything else, and pricing explains plans.