- Documentation
- Integrations
- Apps
- BigCommerce integration
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.
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.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:Resource Level Unlocks Products Modify All 8 product, brand and category actions Customers Modify All 6 customer actions, including every write and the delete Orders Modify list-orders,get-order,update-orderContent Modify create-blog-postCarts Modify get-cartGrant 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 levelget-cartrequests.The webhook triggers do not appear here: BigCommerce registers them against the same account and they need no additional resource permission.
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.
- Store Hash — the segment after
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.
| Trigger | Fires when | BigCommerce scope |
|---|---|---|
bigcommerce/order-created | A new order is created | store/order/created |
bigcommerce/order-updated | Any field on an order changes | store/order/updated |
bigcommerce/order-status-updated | An order moves between statuses | store/order/statusUpdated |
bigcommerce/product-created | A product is added to the catalog | store/product/created |
bigcommerce/product-updated | A product's price, inventory, status or metadata changes | store/product/updated |
bigcommerce/customer-created | A customer record is created | store/customer/created |
bigcommerce/customer-updated | A customer record is updated | store/customer/updated |
bigcommerce/customer-address-created | An address is added to a customer | store/customer/address/created |
bigcommerce/customer-address-updated | A customer address is updated | store/customer/address/updated |
bigcommerce/cart-created | A shopper creates a cart | store/cart/created |
bigcommerce/cart-abandoned | BigCommerce marks a cart abandoned | store/cart/abandoned |
bigcommerce/shipment-created | A shipment is created against an order | store/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}}:
| Trigger | Follow with |
|---|---|
bigcommerce/order-created, order-updated, order-status-updated | bigcommerce/get-order |
bigcommerce/product-created, product-updated | bigcommerce/get-product |
bigcommerce/customer-created, customer-updated | bigcommerce/list-customers (filter by id) |
bigcommerce/customer-address-created, customer-address-updated | bigcommerce/list-customer-addresses |
bigcommerce/cart-created, cart-abandoned | bigcommerce/get-cart |
bigcommerce/shipment-created | bigcommerce/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
| Action | What it does |
|---|---|
bigcommerce/list-products | Lists catalog products |
bigcommerce/get-product | Reads one product by id |
bigcommerce/create-product | Creates a product |
bigcommerce/update-product | Updates a product by id |
bigcommerce/delete-product | Deletes a product by id |
bigcommerce/list-categories | Lists product categories (a flat, paginated list — not the category tree) |
bigcommerce/list-brands | Lists catalog brands |
bigcommerce/create-brand | Creates a brand |
Customers
| Action | What it does |
|---|---|
bigcommerce/list-customers | Finds customers by email, name, company, group, ids or date modified |
bigcommerce/create-customer | Creates a customer (email, first_name, last_name required) |
bigcommerce/update-customer | Updates a customer by numeric id |
bigcommerce/delete-customer | Deletes customers |
bigcommerce/list-customer-addresses | Lists customer addresses |
bigcommerce/create-customer-address | Adds an address to a customer |
Orders and carts
| Action | What it does |
|---|---|
bigcommerce/list-orders | Lists orders |
bigcommerce/get-order | Reads one order by id |
bigcommerce/update-order | Updates an order by id |
bigcommerce/get-cart | Reads one cart by id |
Content
| Action | What it does |
|---|---|
bigcommerce/create-blog-post | Creates 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-customerandupdate-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
200with an emptydataarray rather than an error, so a re-run of the same workflow returns success with nothing to read. Guard downstream steps that expectdata[0]. address_typeaccepts onlyresidentialorcommercial. 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
403on the action rather than a validation error when you publish. - BigCommerce rate-limits per store. A
429is surfaced as a retryable error and retried with backoff. BigCommerce signals the reset window on anX-Rate-Limit-Time-Reset-Msheader, which TaskJuice does not read — the retry schedule is its own, not the provider's — so a workflow hammering one store may see repeated429s before it succeeds. - Webhook events fire after the store transaction commits. A resource id from an event may briefly
404from the matching read endpoint until the upstream cache settles.
Related
- Connect an account — the generic connect flow and the API-key form shape.
- Shopify integration — the other ecommerce platform, for agencies running both.