Manage a BigCommerce store's catalog, orders, customers, carts, inventory, price lists and webhooks over the REST Management API.
BigCommerce ships in the w6w first-party pack. It declares 38 actions, 5 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.bigcommerceBigCommerce runs a merchant’s storefront, and this app manages the store behind it — catalog, orders, customers, carts, inventory, price lists and webhooks — over BigCommerce’s REST Management API.
Beyond core catalog and order operations, it covers order-line detail like shipments, shipping addresses and payment transactions, customer address books, inventory levels across locations, and price lists for multi-currency or wholesale pricing. Webhook management lets a workflow react the moment an order or catalog item changes instead of polling for it.
Under the surface it targets whichever of BigCommerce’s split API versions is actually current for each resource — orders still live on the older surface, catalog and customers on the newer one — so a workflow author doesn’t have to track which version a given operation belongs to. Health checks cover BigCommerce’s own status page, live rate-limit headroom, and the specific store’s own status, so a suspended or trial-expired store shows up distinctly from a platform-wide outage.
Three routes to the same 38 actions. The Workflow tab is generated from BigCommerce's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
cart-create Create a cart from catalog or custom line items. Ask for redirect_urls to get a shoppable checkout link back.
cart-get Fetch one cart by its UUID. There is no way to list carts — you need the id already.
catalog-summary-get Inventory count, variant count, inventory value, variant price range and the largest category — in one call.
category-list List categories across every category tree. Uses the current Category Trees endpoint, not the deprecated flat one.
customer-address-list Customer addresses across the store, filtered by customer, id, company or name.
customer-create Create up to 10 customers in one call. The body is an array, even for one.
customer-list Search customers with the v3 Customers filters. Every filter here is a list form.
customer-update Update up to 10 customers in one call. The body is an array and each element needs its `id`.
inventory-adjust-relative Add to or subtract from stock at a location. The safe form for order-driven changes — deltas compose where absolute writes race.
inventory-item-list Stock levels per item per location. One row per (item, location) pair.
inventory-location-list The store's inventory locations — the source of the location_id an adjustment needs.
order-create Create an order directly. Note this does NOT send the store's order email — create a cart and check it out if the customer should be notified.
order-list Search orders. This is the current Orders API — order CRUD exists only at v2; v3 covers transactions and refunds.
order-product-list The line items on one order. Their `id` is the order_product_id used to ship them.
order-shipment-create Ship some or all of an order's lines. Triggers the store's shipment notification email.
order-shipping-address-list The shipping destinations on one order. Their `id` is the order_address_id a shipment needs.
order-status-list The store's order statuses, with both their system and merchant-customised labels.
order-transaction-list The gateway transactions behind one order — authorisations, captures and refunds.
price-list-list The store's price lists — the containers customer-group and channel pricing hangs off.
price-list-record-list The per-variant, per-currency prices inside one price list.
product-create Create a catalog product. Name, type, price and weight are required by the API.
product-get Fetch a single product by ID, optionally with its variants, images or options.
product-update Apply a partial update to one product. Only the fields you send are changed.
store-get The store's global settings — currency, units, tax-inclusive pricing, timezone, plan, and the default channel and site IDs.
variant-get Fetch one product variant. Both the product ID and the variant ID are required.
variant-list List variants across the catalog. The way to resolve a variant SKU to a product.
variant-update Apply a partial update to one variant — price, SKU, weight, UPC or stock level.
webhook-create Subscribe to a store event. The destination must be HTTPS on port 443 and must answer 200.
webhook-delete Delete one webhook subscription. Only the API account that created it may do so.
webhook-list List webhooks created by THIS API account — webhooks are private to the account that made them, so this is not a store-wide list.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying BigCommerce's real ids.
{
"manifestVersion": "2",
"name": "bigcommerce-example",
"steps": [
{
"id": "abandoned-cart-get",
"uses": {
"app": "io.w6w.bigcommerce",
"action": "abandoned-cart-get",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"token": "<token>"
}
}
]
}abandoned-cart-get brand-list cart-create cart-get catalog-summary-get +33 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for BigCommerce, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to BigCommerce. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "order-create",
payload: {
billingAddress: "<value>",
products: "<value>",
// customerId: "<value>",
// statusId: "<value>",
// channelId: "<value>",
// customerMessage: "<value>",
// staffNotes: "<value>",
// externalSource: "<value>",
// extraFields: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action order-create --payload '{"billingAddress":"<value>","products":"<value>"}' Give an AI agent BigCommerce — without giving it BigCommerce's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.bigcommerce#abandoned-cart-get",
"input": {
"token": "<token>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's BigCommerce connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
BigCommerce's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. BigCommerce itself is MIT, and the runtime that executes it is source-available (FSL).
BigCommerce declares its own checks, so its health is a property of the app rather than something the host guesses at.
Component status from status.bigcommerce.com. Covers `API & Webhooks` (the host this app calls), Storefront, Checkout & Payment Processing, Control Panel, Reporting & Analytics and Email, plus the third-party payment and tax services a store's checkout depends on.
Unauthenticated request to GET /v2/time on api.bigcommerce.com. A 401 passes — it proves the API is resolving and serving this route. It cannot and does not check the store hash or the token; that is the `auth:*` check's job.
Requests left in the store's current 30-second window, read from the X-Rate-Limit-Requests-* headers on a GET /v2/time. The quota is shared by every app on the store, so a low reading may be someone else's traffic.
Reads `status`, `plan_name` and `plan_is_trial` from GET /v2/store. Answers whether THIS store is serving, which a platform-wide status page cannot: a store can be suspended, under maintenance or out of trial while BigCommerce is entirely healthy.