Webhooks Overview

Webhooks notify applications when specific events occur on a BigCommerce store. For example, when:

  • an order is created,
  • a product's inventory changes
  • an item is added to a shopper's cart

This article is an overview of webhook behavior on BigCommerce. For webhook API reference, see API Reference > Webhooks. For webhook event reference, see Webhook Events. For a step-by-step tutorial on creating webhooks for certain store events, see Webhooks Tutorial.

Creating a webhook

To create a webhook, send a POST request to the Create a webhook endpoint. Set the scope property value equal to the Name / Scope of the webhook you want to create.

Example request: Create a webhook
X-Auth-Token: {{ACCESS_TOKEN}}
Content-Type: application/json
Accept: application/json
  "scope": "store/order/updated",
  "destination": "", // custom ports are not supported
  "is_active": true,
  "headers": {}

Webhooks endpoints are available on both the V3 and V2 REST API.

Example response: Create a webhook
  "created_at": 1580329317,
  "destination": "", // custom ports are not supported
  "headers": null,
  "id": 20172984,
  "is_active": true,
  "scope": "store/order/updated",
  "store_hash": "{{STORE_HASH}}",
  "updated_at": 1580329317
  • The destination URL must be served on port 443; custom ports are not currently supported.
  • It can take up to one minute for a newly created webhook to work.
  • A webhook subscription becomes deactivated after 90 days of inactivity.

Callback payload

When a webhook is triggered, BigCommerce will POST a light payload containing event details to the destination server. For example, the data object for store/order/statusUpdated contains only the order id.

Example store/order/statusUpdated payload object

You can then make a request to the Get an order endpoint to obtain full order details.

For more information on specific webhook events and their payloads, see Webhook Events.

Handling callbacks

To acknowledge a callback has been received without issue, the destination server must return an HTTP 200 response — no response, or any response outside the 200 range indicates the callback was not received. If this happens, the webhook service will use the retry mechanism described below.

Duplication of webhook callbacks may occasionally occur due to various factors such as network issues, retries, or other anomalies. We provide mechanisms to detect and handle duplicate callbacks to ensure data integrity and prevent duplicate processing. For more information on webhook duplication, see the Troubleshooting section.

Need to set up a quick webhook destination URL for testing? See Tools for Debugging and Testing Webhooks.

Response requirements

BigCommerce doesn't recommend sending bodies or headers in response to webhooks. It may interfere with the webhook delivery acknowledgment.

BigCommerce has the following webhook response requirements:

If you send response headers, they must conform to the following limitations for the webhook delivery to be successfully acknowledged:

  • The header value should not exceed 8 kilobytes (10 by 1 kilobytes is OK).
  • The header name should not exceed 64 characters (bytes).
  • The total number of headers shouldn't exceed 64.

Callback retry mechanism

The webhooks service will do its best to deliver events to the destination callback URI. It is best practice for the application to respond to the callback before taking any other action that would slow its response. Doing otherwise triggers BigCommerce's callback retry mechanism.

The webhook service may send many payloads to a single URI in quick succession. Because of this, we use a sliding scale across a ** two-minute window** to calculate a callback response success rate for each remote destination. When the webhook service receives a 2xx response, the destination's success count is increased. If there's no response or the remote server times out, the destination's failure count is increased. Based on these two numbers, a success ratio is calculated.

The following process will determine whether the destination URI gets blocklisted:

  1. Once a webhook is triggered, the service checks if your callback URI is on the blocklist.
  2. If it's not, we calculate a success ratio for the remote server based on its success/failure count in a two minute window.
  3. If at any point in the two minute window the success/failure ratio dips below 90%, the destination URI's domain will be blocklisted for three minutes.
  4. Some webhook events triggered during this time are sent to our retry queues for execution later after the domain per specific client_id is no longer blocklisted and once the retry queue time has elapsed.

Blocklisting occurs to the specific client_id, not the entire domain. The webhook service can execute requests for a client_id with less traffic or properly formed requests while blocklisting another client_id on the same domain.

The webhook dispatcher will then attempt several retries (at increasing intervals) until the maximum retry limit is reached.

Retries after 60 seconds
Retries after 180 seconds
Retries after 300 seconds
Retries after 600 seconds
Retries after 900 seconds
Retries after 1800 seconds
Retries after 3600 seconds
Retries after 7200 seconds
Retries after 21600 seconds
Retries after 50400 seconds
Retries after 86400 seconds

After the final retry attempt (cumulatively 48 hours after the first delivery attempt), the webhook will be deactivated, and an email will be sent to the email address registered for the subscribing app. To reactivate the webhook, set is_active back to true using the Update a webhook endpoint.

  • A domain's success rate for a given sliding window is not calculated until 100 webhook requests are sent - this means the domain will not be blocklisted for the first 100 webhooks sent within the time window (regardless of response), as all webhooks are sent until the minimum threshold has been reached for the current time window.
  • The webhook dispatcher determines whether retries are needed based on responses from the subscribed domain as a whole, not by specific hooks. For example, and will affect each other for failures and retries, as both URLs belong to the same domain.

Post app uninstall actions

To avoid accumulating unused webhooks, BigCommerce automatically deletes registered webhooks on app uninstall.

You cannot delete a webhook by deleting the account token used to create it. The associated webhook will continue to run after you delete the token, and you will be unable to edit, delete, or manage the webhook. For information on how to manually delete a webhook, see Delete a Webhook.


To ensure webhook callback requests are secure, BigCommerce takes the following precautions:

  • Webhook payloads contain minimal information about the store and event.
  • Webhook payloads are sent over TLS-encrypted connection.
  • Create Webhook requests to accept an optional header object which can be used to authenticate callbacks requests.
Example request with header object: Create a webhook
X-Auth-Token: {{ACCESS_TOKEN}}
Content-Type: application/json
Accept: application/json
  "scope": "store/cart/lineItem/*",
  "destination": "", // custom ports are not supported
  "is_active": true,
  "headers": {
    "username": "Hello",
    "password": "Goodbye"

BigCommerce will send the specified headers when making callback requests to the destination server - this allows webhook destination URIs to be secured with basic authentication.


Not receiving webhook event callbacks

If your app does not return an HTTP 200 to BigCommerce after receiving the webhook event payload, BigCommerce considers it a failure. BigCommerce will keep trying for a little over 48 hours. At the end of that time, BigCommerce sends an email to the email address set during app registration and disables the webhook by setting the is_active flag to false.

To see if a webhook is still active, send a request to the Get a webhook endpoint and check the value of the is_active property in the response.

If you receive an email, or discover is_active is false, try the following:

  • Verify the app is responding to the callback with a 200 response.
  • Verify the destination server has a valid TLS/SSL setup by visiting Any of the following will cause the TLS/SSL handshake to fail:
    • Self-signed certificates
    • Hostname on certificate doesn't match the hostname in DNS settings
    • Key and trust stores are not configured with the required intermediate certificates

Once the issue is resolved, set is_active to true using the Update a webhook endpoint, so that BigCommerce starts sending event callback requests again.

No 200 response from the Create a webhook endpoint

  • Check TLS/SSL configuration on the computer sending the request.
  • Verify POST request contains the following required HTTP headers:
Example request with required headers: Create a webhook
Accept: application/json
Content-Type: application/json
X-Auth-Token: {{ACCESS_TOKEN}}

Unable to view your webhook

Webhooks created with one token are not visible when you retrieve webhooks using a different token. To view your webhook, use the same account token that created the webhook.

Webhooks timing out

To prevent your webhooks from timing out, send a 200 success status response immediately after receiving the request.

What are duplicate events?

In our event-based system, events are like messages that trigger actions within the system. Sometimes, for various reasons, these events can be received or processed more than once, causing "duplicate events."

Why do duplicate events happen?

Duplicate events can occur for several reasons:

  • Network Glitches: Internet connections or network delays can cause events to be sent or received more than once.
  • System Hiccups: If parts of our system experience temporary glitches or outages, they might inadvertently send the same event multiple times when they recover.
  • Message Retries: When messages fail to reach their destination, our system automatically retries sending them. Occasionally, this causes duplicate events to be processed.

How do you prevent duplicate events?

BigCommerce recommends that apps use idempotent operations to prevent unintended side effects. Idempotent operations allow multiple calls without changing the result. One approach to ensuring webhook events maintain idempotence is by creating a temporary 'blocklist' array to store the hashes of webhooks that have already been received or handled. When you receive a webhook, you can compare the hash of the received event to the list. If the hash has already been handled you can ignore the event.


Below is a collection of third-party tools that can be used to aid in the development, testing, and debugging of webhooks:

ngrok (opens in a new tab)Easily set up tunnels between localhost and an ngrok public URL to test callback requests on your machine
Webhook Tester (opens in a new tab)Test webhooks and other HTTP requests in your browser

Related resources



Did you find what you were looking for?