Ecwid
Manage an Ecwid store: products and stock, categories, orders, customers, discount coupons and the store profile.
About
Ecwid ships in the w6w first-party pack. It declares 23 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
- App id
io.w6w.ecwid- Version
- 0.1.0
- Author
- w6w
- Licence
- MIT
- Categories
- Commerce & Payments · Productivity
Overview
Ecwid by Lightspeed is an eCommerce platform, and this app covers the store management a workflow actually automates: the product catalog and its stock, the category tree, orders from placement to fulfillment, customer records, discount coupons, and the store’s own profile and settings.
Everything a store-run needs to react to is here. Search the catalog by keyword, SKU, category or availability and write products back with their variations’ stock; move stock by delta so a sale or a return never clobbers a concurrent one; read and amend orders with their totals, addresses and statuses; find customers by name, email, phone or group and keep their consents and tax details straight; and create the coupons a campaign hands out. The store profile read returns the settings, languages, formats and company address that the rest of the store is configured from.
The connection is a single store — an Ecwid store id plus a custom app’s secret access token, sent as a bearer token with the id in every request’s path — which is the configuration Ecwid’s own documentation recommends for single-store integrations instead of an OAuth app. Health checks follow Ecwid’s own status page, keyed on its API component rather than the page-wide roll-up, and the app states plainly that Ecwid publishes no readable quota headroom rather than inventing a probe for it.
Build with Ecwid
Three routes to the same 23 actions. The Workflow tab is generated from Ecwid'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.
Create Category
category-create Create a category. The name is required; the API puts it at the top level unless a parent is given.
Delete Category
category-delete Delete a category. Products assigned to it are kept and simply lose the assignment.
Get Category
category-get Fetch one category, optionally with the ids of the products assigned to it.
Update Category
category-update Update a category. Fields left empty are not sent, so they keep their current value.
Search Customers
customer-search Search customer records by name, email, phone, group or registration date.
Update Customer
customer-update Update a customer's email, addresses, contacts, group, tax status or marketing consent.
Create Discount Coupon
discount-coupon-create Create a discount coupon with a code, a discount type and its limits.
Search Discount Coupons
discount-coupon-search Search discount coupons by code, type, availability or creation date.
Create Order
order-create Create an order. Email, subtotal, total and both statuses are required by the API; Ecwid stores the totals you send rather than recalculating them.
Create Product
product-create Create a catalog product. Name, price and SKU are required by the API.
Delete Product
product-delete Delete a product. Returns the vendor's `deleteCount`: 1 if it was deleted, 0 if it was not.
Search Products
product-search Search the store's catalog by keyword, SKU, category, availability or enabled state.
Adjust Product Stock
product-stock-adjust Add to or subtract from a product's stock on hand by a delta — the safe way to reflect a sale or a return without overwriting concurrent changes.
Update Product
product-update Update a product. Fields left empty are not sent, so they keep their current value.
Get Store Profile
store-profile-get Read the store profile: general info, storefront settings, company address, languages and formats and units.
Update Store Profile
store-profile-update Update store settings, store URL, company details or enabled languages. Fields not sent are left untouched.
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 Ecwid's real ids.
{
"manifestVersion": "2",
"name": "ecwid-example",
"steps": [
{
"id": "category-create",
"uses": {
"app": "io.w6w.ecwid",
"action": "category-create",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"name": "<name>"
}
}
]
}Here are some of the things you can do
-
Create Category
performcategory-create -
Get Category
readcategory-get -
Search Categories
searchcategory-search -
Update Category
performcategory-update -
Create Customer
performcustomer-create
+18 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 Ecwid, 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 Ecwid. 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: "category-create",
payload: {
name: "<value>",
// parentId: "<value>",
// orderBy: "<value>",
// description: "<value>",
// enabled: "<value>",
// seoTitle: "<value>",
// seoDescription: "<value>",
// customSlug: "<value>",
// extraFields: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value);npm install -g @w6w/cliw6w run conn_YOUR_CONNECTION_ID --action category-create --payload '{"name":"<value>"}'Give an AI agent Ecwid — without giving it Ecwid'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.ecwid#category-create",
"input": {
"name": "<name>"
}
}
}
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 Ecwid 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
Ecwid'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. Ecwid itself is MIT, and the runtime that executes it is source-available (FSL).
Health checks
Ecwid declares its own checks, so its health is a property of the app rather than something the host guesses at.
Ecwid platform status
The `API` component on status.ecwid.com — the component that speaks for app.ecwid.com. Storefront, Checkout, Admin, Billing and Third-party services are reported as detail but never drive the verdict.