Skip to main content

BigCommerce integration

Manage products, orders, customers, and carts, and react to store events for your clients' BigCommerce stores.

What it does

The BigCommerce integration lets your agency run catalog, order, customer, and cart operations on behalf of your clients without leaving TaskJuice. Connect a client's store once and your workflows can list and mutate products, read and update orders, create and update customers and their addresses, manage brands and categories, publish blog posts, and read carts. Twelve webhook triggers start workflows the moment something happens in the store.

Connect a BigCommerce store

BigCommerce connections use a store-level API account that the merchant creates in their own control panel. Nothing is installed into the client's store, no TaskJuice-branded app appears in their app list, and there is no review process — the merchant creates the account in about a minute and hands you three values.

  1. Create a store API account in BigCommerce

    In the client's BigCommerce control panel, go to Settings → Store-level API accounts and click Create API account. Give it a name the merchant will recognise later, such as TaskJuice.

  2. Grant the scopes your workflows need

    The create-account form is a per-resource permission matrix — each resource is set to none, read-only, or modify — not a consent screen. A level set too low does not block publishing; it fails the action at runtime with a 403. Set at minimum:

    ResourceLevelUnlocks
    ProductsModifyAll 8 product, brand and category actions
    CustomersModifyAll 6 customer actions, including every write and the delete
    OrdersModifylist-orders, get-order, update-order
    ContentModifycreate-blog-post
    CartsModifyget-cart

    Grant modify only on the resources whose actions you actually use — a workflow that only reads orders needs Orders at modify just for update-order, and nothing at all for the others. Carts needs modify rather than read-only because that is the permission level get-cart requests.

    The webhook triggers do not appear here: BigCommerce registers them against the same account and they need no additional resource permission.

  3. Copy all three values before you leave the screen

    BigCommerce shows the credentials exactly once, when the account is created. Copy all of them now — if the screen is dismissed, the only recovery is to create a new API account.

    • Store Hash — the segment after /stores/ in the API path shown on this screen (https://api.bigcommerce.com/stores/abc123def/ → abc123def). It is also the alphanumeric id in the control-panel URL, https://store-abc123def.mybigcommerce.com/.
    • Access Token — the token TaskJuice sends on every request.
    • Client Secret — TaskJuice never sends this to BigCommerce. It is the key used to verify that incoming store webhooks are genuine.
  4. Connect in TaskJuice

    Open your workspace, go to Connections, choose BigCommerce, and paste Store Hash, Access Token and Client Secret into the three fields.

    Create this connection at account scope, as an account admin, if you want to use the twelve webhook triggers. The client secret doubles as the key that verifies incoming webhooks, and that key is held once per account — so only an account-scope connection is allowed to set it.

    You can also send the client a credential request and have them fill the same three fields themselves — the client portal shows the identical labels. A client-supplied connection is workspace-scoped: every one of the nineteen actions works on it, but it does not set the webhook verification key, so triggers need an account-scope connection as well. See Known limitations.

To revoke access, delete the API account you created under Settings → Store-level API accounts. That immediately invalidates the access token and stops webhook deliveries from verifying.

For the general connect flow, see Connect an account.

Triggers

All twelve triggers are BigCommerce webhooks. TaskJuice registers them with the store for you when you publish a workflow that uses one — there is nothing to configure in the control panel.

Triggers verify against the client secret from an account-scope BigCommerce connection. If the only connection for the app was supplied by a client through the portal or a credential link, actions will run but deliveries will not verify — add an account-scope connection to fix it.

TriggerFires whenBigCommerce scope
bigcommerce/order-createdA new order is createdstore/order/created
bigcommerce/order-updatedAny field on an order changesstore/order/updated
bigcommerce/order-status-updatedAn order moves between statusesstore/order/statusUpdated
bigcommerce/product-createdA product is added to the catalogstore/product/created
bigcommerce/product-updatedA product's price, inventory, status or metadata changesstore/product/updated
bigcommerce/customer-createdA customer record is createdstore/customer/created
bigcommerce/customer-updatedA customer record is updatedstore/customer/updated
bigcommerce/customer-address-createdAn address is added to a customerstore/customer/address/created
bigcommerce/customer-address-updatedA customer address is updatedstore/customer/address/updated
bigcommerce/cart-createdA shopper creates a cartstore/cart/created
bigcommerce/cart-abandonedBigCommerce marks a cart abandonedstore/cart/abandoned
bigcommerce/shipment-createdA shipment is created against an orderstore/shipment/created

Every trigger delivers IDENTIFIERS, not the record

This is the one thing to know before you build a BigCommerce workflow. A delivery's body is the envelope only:

{
  "scope": "store/order/created",
  "store_id": "1025646",
  "producer": "stores/abc123def",
  "created_at": 1748131200,
  "hash": "…",
  "data": { "type": "order", "id": 250 }
}

There are no order fields, no product fields, no customer fields on the activation. Mapping {{trigger.total_inc_tax}} or {{trigger.email}} yields nothing. To act on the record, follow the trigger with the matching read action and pass {{trigger.data.id}}:

TriggerFollow with
bigcommerce/order-created, order-updated, order-status-updatedbigcommerce/get-order
bigcommerce/product-created, product-updatedbigcommerce/get-product
bigcommerce/customer-created, customer-updatedbigcommerce/list-customers (filter by id)
bigcommerce/customer-address-created, customer-address-updatedbigcommerce/list-customer-addresses
bigcommerce/cart-created, cart-abandonedbigcommerce/get-cart
bigcommerce/shipment-createdbigcommerce/get-order on {{trigger.data.orderId}} — BigCommerce publishes no read-one-shipment endpoint

How deliveries are verified

BigCommerce HTTPS webhooks follow the Standard Webhooks specification. Each delivery carries webhook-id, webhook-timestamp and webhook-signature headers. TaskJuice recomputes the base64 HMAC-SHA256 of {webhook-id}.{webhook-timestamp}.{body}, keyed with your store API account's client secret, and compares it against the webhook-signature value, which BigCommerce prefixes with v1,. The timestamp is epoch seconds and must be within a 300-second window. Deliveries that fail either check are rejected before they reach your workflow.

Identifying the store on a delivery

The activation payload's producer field carries stores/<hash> — the store hash. The separate store_id field is the numeric BigCommerce store id, not the hash, so building an API path from store_id will 404. Use the connection's store hash (or producer) wherever a path needs it.

Actions

Products and catalog

ActionWhat it does
bigcommerce/list-productsLists catalog products
bigcommerce/get-productReads one product by id
bigcommerce/create-productCreates a product
bigcommerce/update-productUpdates a product by id
bigcommerce/delete-productDeletes a product by id
bigcommerce/list-categoriesLists product categories (a flat, paginated list — not the category tree)
bigcommerce/list-brandsLists catalog brands
bigcommerce/create-brandCreates a brand

Customers

ActionWhat it does
bigcommerce/list-customersFinds customers by email, name, company, group, ids or date modified
bigcommerce/create-customerCreates a customer (email, first_name, last_name required)
bigcommerce/update-customerUpdates a customer by numeric id
bigcommerce/delete-customerDeletes customers
bigcommerce/list-customer-addressesLists customer addresses
bigcommerce/create-customer-addressAdds an address to a customer

Orders and carts

ActionWhat it does
bigcommerce/list-ordersLists orders
bigcommerce/get-orderReads one order by id
bigcommerce/update-orderUpdates an order by id
bigcommerce/get-cartReads one cart by id

Content

ActionWhat it does
bigcommerce/create-blog-postCreates a blog post — a draft unless you set is_published

Known limitations

  • One verified store per workspace tenant. The webhook signing key is stored per tenant and app, so connecting a second BigCommerce store overwrites the first store's signing secret and the first store's deliveries stop verifying. If you automate more than one client store, keep each in its own tenant.
  • Only an account-scope connection sets up triggers. The webhook verification key is held once per account, not per workspace, so TaskJuice only lets an account-scope connection set it — a workspace-scope connection cannot change the key every other workspace in the account depends on. A connection a client supplies through the portal or a credential link is workspace-scoped, so it runs all nineteen actions but does not enable the twelve triggers. To use triggers, an account admin adds an account-scope BigCommerce connection with the same store's client secret; the client-supplied connection keeps working for actions alongside it.
  • Connections are scoped to one store hash. Create one connection per store. Re-entering the same store hash rotates the existing connection rather than creating a duplicate.
  • The customer writes handle one record per step. BigCommerce accepts up to 10 customers per call on create-customer and update-customer; TaskJuice sends one and lets you drive volume with a Loop node, which keeps every call inside the cap.
  • Creating an address that already exists succeeds silently. BigCommerce treats the whole address as the uniqueness key and answers 200 with an empty data array rather than an error, so a re-run of the same workflow returns success with nothing to read. Guard downstream steps that expect data[0].
  • address_type accepts only residential or commercial. The field is a picker in the workflow editor for this reason.
  • Scopes are enforced at runtime, not at publish. The permission matrix lives on the merchant's API account, which TaskJuice cannot read, so a level set too low surfaces as a 403 on the action rather than a validation error when you publish.
  • BigCommerce rate-limits per store. A 429 is surfaced as a retryable error and retried with backoff. BigCommerce signals the reset window on an X-Rate-Limit-Time-Reset-Ms header, which TaskJuice does not read — the retry schedule is its own, not the provider's — so a workflow hammering one store may see repeated 429s before it succeeds.
  • Webhook events fire after the store transaction commits. A resource id from an event may briefly 404 from the matching read endpoint until the upstream cache settles.
Was this helpful?