Webhooks & Apps

Beyond theme customization, BigCommerce supports full apps — separate pieces of software, installed by a merchant, that extend a store's functionality through the Management API and react to events through webhooks. This lesson covers both, plus how an app can add its own UI into the control panel.

What a BigCommerce app is

An app is typically a web application hosted outside BigCommerce, installed into a specific store, and granted API access scoped to what it actually needs — inventory sync, reviews, loyalty programs, and similar third-party functionality are usually delivered this way rather than baked into a theme.

OAuth and authentication

A public app authenticates via OAuth: a merchant approves the app's requested scopes during installation, and BigCommerce issues the app an access token scoped to that specific store — the same shape as Shopify's app authentication model, though the specific handshake differs:

HTTP using an app's access token

GET /stores/{store_hash}/v3/catalog/products
Host: api.bigcommerce.com
X-Auth-Token: {access_token}

Registering a webhook

Webhooks are created through the Management API, specifying a scope (the event to watch for) and a destination URL:

HTTP creating a webhook

POST /stores/{store_hash}/v3/hooks
Host: api.bigcommerce.com
X-Auth-Token: {access_token}
Content-Type: application/json

{
  "scope": "store/order/created",
  "destination": "https://myapp.example.com/webhooks/order-created",
  "is_active": true
}

From then on, every new order triggers a POST request to that destination — but a lean one. Unlike some platforms, BigCommerce doesn't stuff the entire order into the payload; it sends just enough to identify what happened (store, scope, and the affected resource's ID), leaving your server to call the Management API back for full details if it needs them.

How BigCommerce actually secures webhook delivery

It's worth being precise here, since it's easy to assume every platform's webhooks are cryptographically signed the way some are — BigCommerce's aren't. Delivery security instead rests on the transport itself (webhooks are only ever sent over HTTPS) and on an optional authentication header you configure yourself when creating the webhook, rather than a signature BigCommerce computes and attaches to the payload. Every payload does include a hash value, but its role is different from a signature: it's meant for detecting and discarding duplicate deliveries, not for proving the request's authenticity.

JavaScript a webhook handler that de-duplicates by hash

app.post('/webhooks/order-created', (req, res) => {
  const { hash, data } = req.body;
  if (seenHashes.has(hash)) return res.sendStatus(200);
  seenHashes.add(hash);

  console.log('New order:', data.id);
  res.sendStatus(200);
});

If a handler needs stronger assurance that a request genuinely came from BigCommerce, the practical approach is to set a custom header with a shared secret when registering the webhook, and check for that header on every incoming request — the platform doesn't provide an HMAC-style signature to verify instead.

Retries

A failed delivery isn't retried just once — BigCommerce backs off over an increasingly long schedule stretching across roughly two days before giving up, and a destination that fails too often in a short window gets temporarily skipped. Responding quickly with a success status, and doing slower work (emails, database writes) afterward, keeps a handler from tripping that failure threshold under normal load.

App extensions in the control panel

Beyond webhooks and API access, an installed app can register app extensions — iframe-embedded panels that appear directly inside the BigCommerce control panel (on an order page, a product page, or the main navigation), letting a merchant interact with the app without leaving the admin interface. This is how apps like shipping calculators or review moderation tools feel like a native part of the platform rather than a separate site.

Note: because BigCommerce doesn't sign webhook payloads the way some platforms do, treat the hash field purely as a de-duplication tool — never as proof that a request is legitimate. A custom auth header you control is what actually stands in for verification here.

PreviousWidgets & Page Builder NextFaceted Search