First-party app
BigCommerce BigCommerce

BigCommerce

Manage a BigCommerce store's catalog, orders, customers, carts, inventory, price lists and webhooks over the REST Management API.

stable Commerce & PaymentsCustomer Relationship Management

About

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.

App id
io.w6w.bigcommerce
Version
0.1.3
Author
w6w
Licence
MIT
Categories
Commerce & Payments · Customer Relationship Management

Overview

BigCommerce 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.

Build with BigCommerce

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.

Get Abandoned Cart

abandoned-cart-get

Fetch an abandoned cart by the token from its recovery link.

List Brands

brand-list

List catalog brands, optionally filtered by exact or partial name.

Create Cart

cart-create

Create a cart from catalog or custom line items. Ask for redirect_urls to get a shoppable checkout link back.

Get Cart

cart-get

Fetch one cart by its UUID. There is no way to list carts — you need the id already.

Get Catalog Summary

catalog-summary-get

Inventory count, variant count, inventory value, variant price range and the largest category — in one call.

List Categories

category-list

List categories across every category tree. Uses the current Category Trees endpoint, not the deprecated flat one.

List Category Trees

category-tree-list

List category trees and the channels each one serves.

List Customer Addresses

customer-address-list

Customer addresses across the store, filtered by customer, id, company or name.

Create Customers

customer-create

Create up to 10 customers in one call. The body is an array, even for one.

List Customers

customer-list

Search customers with the v3 Customers filters. Every filter here is a list form.

Update Customers

customer-update

Update up to 10 customers in one call. The body is an array and each element needs its `id`.

Adjust Inventory (Relative)

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.

List Inventory

inventory-item-list

Stock levels per item per location. One row per (item, location) pair.

List Inventory Locations

inventory-location-list

The store's inventory locations — the source of the location_id an adjustment needs.

Count Orders

order-count

Total order count plus a per-status breakdown, optionally filtered.

Create Order

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.

Get Order

order-get

Fetch one order by ID.

List Orders

order-list

Search orders. This is the current Orders API — order CRUD exists only at v2; v3 covers transactions and refunds.

List Order Products

order-product-list

The line items on one order. Their `id` is the order_product_id used to ship them.

Create Order Shipment

order-shipment-create

Ship some or all of an order's lines. Triggers the store's shipment notification email.

List Order Shipping Addresses

order-shipping-address-list

The shipping destinations on one order. Their `id` is the order_address_id a shipment needs.

List Order Statuses

order-status-list

The store's order statuses, with both their system and merchant-customised labels.

List Order Transactions

order-transaction-list

The gateway transactions behind one order — authorisations, captures and refunds.

Update Order

order-update

Apply a partial update to one order — most often to change its status.

List Price Lists

price-list-list

The store's price lists — the containers customer-group and channel pricing hangs off.

List Price List Records

price-list-record-list

The per-variant, per-currency prices inside one price list.

Create Product

product-create

Create a catalog product. Name, type, price and weight are required by the API.

Delete Product

product-delete

Permanently delete one product by ID. There is no undo.

Get Product

product-get

Fetch a single product by ID, optionally with its variants, images or options.

List Products

product-list

Search the store's catalog with the v3 Products filters.

Update Product

product-update

Apply a partial update to one product. Only the fields you send are changed.

Get Store Information

store-get

The store's global settings — currency, units, tax-inclusive pricing, timezone, plan, and the default channel and site IDs.

Get Variant

variant-get

Fetch one product variant. Both the product ID and the variant ID are required.

List Variants

variant-list

List variants across the catalog. The way to resolve a variant SKU to a product.

Update Variant

variant-update

Apply a partial update to one variant — price, SKU, weight, UPC or stock level.

Create Webhook

webhook-create

Subscribe to a store event. The destination must be HTTPS on port 443 and must answer 200.

Delete Webhook

webhook-delete

Delete one webhook subscription. Only the API account that created it may do so.

List Webhooks

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>"
      }
    }
  ]
}

Here are some of the things you can do

  • Get Abandoned Cart

    read
    abandoned-cart-get
  • List Brands

    search
    brand-list
  • Create Cart

    perform
    cart-create
  • Get Cart

    read
    cart-get
  • Get Catalog Summary

    read
    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.

Install
npm install @w6w/sdk
yarn add @w6w/sdk
pnpm add @w6w/sdk
deno add npm:@w6w/sdk
Code
import { 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);
Install the CLI
npm install -g @w6w/cli
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.

What the agent gets

Credentials it can't read

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.

A tool surface scoped to the caller

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.

A durable workflow in one call

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.

Health-aware discovery

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).

Request MCP access

Health checks

BigCommerce declares its own checks, so its health is a property of the app rather than something the host guesses at.

service

BigCommerce platform status

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.

dependency

API reachable

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.

quota

Request quota headroom

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.

dependency

Store live

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.

quota

Plan object-limit headroom