Squarespace Commerce for one merchant site: orders, inventory, products, store pages, profiles and transactions.
Squarespace Commerce ships in the w6w first-party pack. It declares 21 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.squarespace-commerceSquarespace’s Commerce APIs are the merchant-side surface of a Squarespace store — the orders it received, the inventory and products behind them, the store pages they are published on, the customer profiles that placed them and the transaction documents that record the money. This app covers exactly that surface, and deliberately nothing else: no Content API, no Forms API, no Webhook Subscriptions, no Contacts, no Discounts and no Analytics.
The everyday path is the one a store operator actually walks: list or fetch an order, read the inventory items a fulfilment depends on, adjust stock, and publish or edit the products and variants the catalogue is built from. A workflow can also create an order on behalf of an external sales channel and mark it fulfilled, and — for reconciliation — list the transaction documents for one specific order.
Health checks read Squarespace’s own Statuspage feed, scoped to its Commerce component, and the credential probe is the same website-profile lookup users get as an action. Authentication is an API key only; OAuth is reserved for registered Squarespace Extensions and is out of scope here.
Three routes to the same 21 actions. The Workflow tab is generated from Squarespace Commerce'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.
adjust-inventory Increment, decrement, set or un-track stock for specific variants. At least one operation array is required; an Idempotency-Key is stamped for you.
create-order Create an order from an external sales channel. Squarespace requires `channelName`, `createdOn`, `externalOrderReference`, `fulfillments`, `grandTotal`, `lineItems` and `priceTaxInterpretation`; an `Idempotency-Key` is stamped for you.
create-product Create a PHYSICAL, SERVICE or GIFT_CARD product on a store page. `DIGITAL` products cannot be created through the API.
create-product-variant Add a variant to a product. `sku` (≤60 characters, unique per product) and `pricing` are required; `attributes`, `gtin`, `mpn`, `shippingMeasurements` and `stock` are physical-product-only.
delete-product Delete a product (and its variants and inventory rows) by id. Squarespace answers 204; this is irreversible.
delete-product-variant Delete one variant from a product. Squarespace answers 204 and refuses to remove the product's last variant.
fulfill-order Mark an order fulfilled, optionally recording shipments and notifying the customer. Squarespace answers 204 with no body.
get-inventory-items Retrieve inventory for up to 50 specific variant ids in one request. No pagination: unknown ids are omitted from the response.
get-transactions Retrieve up to 50 specific transaction documents by comma-separated id.
get-website-profile Retrieve the website the connected API key belongs to: its title, URL, currency, language, time zone and measurement standard. Takes no parameters.
list-inventory List up to 50 inventory items (one per tracked variant) with their SKU, quantity and unlimited flag.
list-orders List up to 50 orders for the website, ordered by modified date. Filter by customer, fulfillment status, payment state, or a modified-date window.
list-products List up to 50 products, optionally filtered by a free-text query, a modified-date window, or one or more product types.
list-profiles List up to 50 customer profiles with their contact details and order summary. Note the vendor's maintenance notice: this API stays live, but new integrations are pointed at its Contacts API instead.
list-store-pages List the website's store pages. A page's `id` is the `storePageId` that creating a product requires.
list-transactions List up to 50 transaction documents, ordered by modified date. Filter by order id to read one order's payments, refunds and fees.
update-product Update a product's name, description, visibility, tags, URL slug, pricing, attribute names or SEO data. Every field is optional and sent in Squarespace's `{present, value}` Change wrapper, which this action builds for you.
update-product-variant Update a variant's SKU, pricing, attributes, GTIN, MPN, shipping measurements or stock. Every field is optional and sent in Squarespace's `{present, value}` Change wrapper, which this action builds for you.
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 Squarespace Commerce's real ids.
{
"manifestVersion": "2",
"name": "squarespace-commerce-example",
"steps": [
{
"id": "create-order",
"uses": {
"app": "io.w6w.squarespace-commerce",
"action": "create-order",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"channelName": "<channelName>",
"createdOn": "<createdOn>",
"externalOrderReference": "<externalOrderReference>"
}
}
]
}create-order adjust-inventory create-product create-product-variant fulfill-order +16 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 Squarespace Commerce, 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 Squarespace Commerce. 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: "create-order",
payload: {
channelName: "<value>",
createdOn: "<value>",
externalOrderReference: "<value>",
grandTotal: "<value>",
lineItems: "<value>",
fulfillments: "<value>",
priceTaxInterpretation: "<value>",
// fulfillmentStatus: "<value>",
// fulfilledOn: "<value>",
// customerEmail: "<value>",
// inventoryBehavior: "<value>",
// shopperFulfillmentNotificationBehavior: "<value>",
// subtotal: "<value>",
// taxTotal: "<value>",
// shippingTotal: "<value>",
// discountTotal: "<value>",
// discountLines: "<value>",
// shippingLines: "<value>",
// billingAddress: "<value>",
// shippingAddress: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action create-order --payload '{"channelName":"<value>","createdOn":"<value>","externalOrderReference":"<value>","grandTotal":"<value>","lineItems":"<value>","fulfillments":"<value>","priceTaxInterpretation":"<value>"}' Give an AI agent Squarespace Commerce — without giving it Squarespace Commerce'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.squarespace-commerce#create-order",
"input": {
"channelName": "<channelName>",
"createdOn": "<createdOn>",
"externalOrderReference": "<externalOrderReference>"
}
}
}
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 Squarespace Commerce 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.
Squarespace Commerce'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. Squarespace Commerce itself is MIT, and the runtime that executes it is source-available (FSL).
Squarespace Commerce declares its own checks, so its health is a property of the app rather than something the host guesses at.
The `Commerce` component on status.squarespace.com — the component that speaks for api.squarespace.com's commerce routes. The page's other twelve components (Site Loading, the editor, Domains, Email Campaigns, Acuity Scheduling, …) are reported as detail but never drive the verdict, and the page-level indicator is only ever named.
Not readable: Squarespace documents fixed ceilings (300 requests/minute, and 100/hour on Create order with an API key) but publishes no rate-limit response headers and no balance or usage endpoint.