The world's most widely deployed e-commerce platform — WordPress-native and open source. REST API v3 exposes the entire store: products, orders, customers, inventory, coupons, reports. Basic Auth with Consumer Key and Secret, HMAC-signed webhooks, and the flexibility (and chaos) that comes with plugin-land.
WooCommerce is e-commerce as a WordPress plugin. It powers an estimated third of online stores on the open web — mostly long-tail retailers, content-led brands, and operators who want full control over their stack instead of renting it from a SaaS. Modern installs expose a REST API v3 over the WordPress REST infrastructure, and that's the surface this skill targets.
The scope is wide. Everything the WordPress admin can do through the UI is available through the API — products (simple and variable), orders, customers, inventory, coupons, reports, webhooks, and the usual WordPress plumbing underneath.
The 2nth model: one person + one AI. Same frame as Shopify — six human roles, each with an AI partner. The mapping is almost identical because the job is the same. What differs is what's underneath: WooCommerce gives you more flexibility but also more surface area to keep in sync (plugins, themes, hosting, WordPress core).
| Role | The human decides | The AI enables |
|---|---|---|
| Store Owner | Strategy, margins, supplier relationships | Revenue dashboards, profitability by category, reorder alerts |
| Merchandiser | Range planning, pricing, promotions | Bulk product updates, auto-tagging, SEO title/description generation |
| Content Creator | Brand voice, creative direction | Product descriptions, meta tags, alt text, blog content |
| Customer Service | Escalations, refunds, relationship calls | Order lookup, draft responses, return eligibility checks |
| Operations | Exception handling, carrier selection | Stock alerts, fulfilment routing, fraud flag review |
| Marketing Manager | Campaign strategy, budget | Coupon performance, customer segmentation, repeat purchase analysis |
Product, order, and customer state all live in WordPress's database. The REST API reads and writes through WooCommerce's own hooks — which means your mutations fire the same events plugins expect. Never bypass the API to write directly to wp_posts; you'll skip the hooks and break other plugins silently.
WooCommerce authenticates with a Consumer Key and Consumer Secret generated per integration. HTTP Basic over HTTPS — refuses anything else. Simple, effective, easy to scope.
# Generate keys: WooCommerce → Settings → Advanced → REST API → Add key # Pick Read, Read/Write, or Read/Write/Delete per key # Environment variables WC_URL="https://yourstore.com" WC_KEY="ck_xxxxxxxxxxxxxxxxxxxxxxxxxxxx" WC_SECRET="cs_xxxxxxxxxxxxxxxxxxxxxxxxxxxx" # Basic Auth header (HTTPS only) Authorization: Basic base64(WC_KEY:WC_SECRET) # Base URL pattern https://{store}/wp-json/wc/v3/{resource}
// Cloudflare Worker — WooCommerce list call const auth = 'Basic ' + btoa(`${env.WC_KEY}:${env.WC_SECRET}`); const res = await fetch( `${env.WC_URL}/wp-json/wc/v3/products?status=publish&per_page=100`, { headers: { 'Authorization': auth } } ); const products = await res.json();
Generate a Read-only key for the reporting agent. A Read/Write key for fulfilment and stock updates. Never give an agent Read/Write/Delete unless it's literally managing product deletion — and even then, favour soft-delete (change status to trash) over hard-delete. The UI still offers the key as query parameters; don't use that path in production.
The REST endpoints cover everything. The interesting bits are the variable-product structure (variations are separate resources), the batch endpoint (up to 100 operations per call), and the webhook signature verification that keeps reactive flows honest.
Products. The central resource. Simple products are single SKUs; variable products own a set of variations with their own stock. Never update stock on the parent of a variable product — you'll silently do nothing.
# List active products GET /wp-json/wc/v3/products?status=publish&per_page=100 # Create a simple product POST /wp-json/wc/v3/products { "name": "Product Name", "type": "simple", # simple | variable | grouped | external "regular_price": "299.00", "description": "...", "short_description": "...", "categories": [{"id": 12}], "images": [{"src": "https://..."}], "manage_stock": true, "stock_quantity": 50 } # Variable product — variations live at a sub-resource GET /wp-json/wc/v3/products/{product_id}/variations PUT /wp-json/wc/v3/products/{product_id}/variations/{variation_id} { "stock_quantity": 25 }
Batch operations. One call, up to 100 updates. This is the right way to do bulk price changes, stock syncs, or status transitions — much faster than iterating per-product and easier on the host.
POST /wp-json/wc/v3/products/batch
{
"update": [
{ "id": 101, "stock_quantity": 0, "stock_status": "outofstock" },
{ "id": 102, "stock_quantity": 15 },
{ "id": 103, "regular_price": "199.00" }
],
"delete": [456]
}
Orders — the full lifecycle. Plugin-land means order status is a string, not an enum: plugins add custom statuses like wc-awaiting-payment. Always check what statuses the specific store actually uses before assuming.
# List by status GET /wp-json/wc/v3/orders?status=processing&per_page=50 # pending | processing | on-hold | completed | cancelled | refunded | failed | trash # Update status PUT /wp-json/wc/v3/orders/{id} { "status": "completed" } # Add a note (internal or customer-visible) POST /wp-json/wc/v3/orders/{id}/notes { "note": "Dispatched via FastShip, tracking: FS123456", "customer_note": true } # Create refund (partial or full) POST /wp-json/wc/v3/orders/{id}/refunds { "amount": "50.00", "reason": "Damaged in transit", "line_items": [{"id": 1, "refund_total": 50.00}] }
AI workflow patterns — what the role-tool matrix actually does. Four patterns lifted straight from the canonical skill that show the shape of day-to-day AI work against a WooCommerce store.
wc_list_orders(status=processing) — pending fulfilment countwc_low_stock_report() — items needing reorderwc_sales_report(period=yesterday) — revenue vs targetwc_get_product(id) — fetch existing datawc_update_product — write description, short_description, SEO metawc_list_customers(last_active_before=90d)wc_create_coupon — unique code attached to each emailHMAC-signed webhooks — verify every payload. WooCommerce signs webhook bodies with HMAC-SHA256 using the webhook secret. Verify before trusting. The signature comes through as an X-WC-Webhook-Signature header.
// Cloudflare Worker — verify a WooCommerce webhook const sig = request.headers.get('X-WC-Webhook-Signature'); const body = await request.text(); const key = await crypto.subtle.importKey( 'raw', new TextEncoder().encode(env.WC_WEBHOOK_SECRET), { name: 'HMAC', hash: 'SHA-256' }, false, ['sign'] ); const mac = await crypto.subtle.sign('HMAC', key, new TextEncoder().encode(body)); const expected = btoa(String.fromCharCode(...new Uint8Array(mac))); if (sig !== expected) return new Response('Unauthorized', { status: 401 });
Every one of these has cost someone an afternoon. WooCommerce's flexibility is its strength and its trap — plugins add behaviour, themes add filters, hosts add caching. Assume nothing.
The REST API rejects every request over plain HTTP — even in local dev. Use ngrok, Local by Flywheel, or a self-signed cert on localhost.
Paginate with ?page=2&per_page=100. The X-WP-TotalPages response header tells you how many pages exist. Don't use larger per-page values — WP silently caps them.
A variable product's stock lives on its variations, not the parent. Updating stock_quantity on the parent does nothing. Always go through /products/{id}/variations.
Split larger bulk updates into chunks of 100 or fewer. Over 100 ops and the whole batch fails.
Plugins add custom statuses (wc-awaiting-payment, wc-backorder). Always check what the store actually uses before filtering — don't assume the default set.
Create a Read-only key for the reporting agent. A Read/Write key for fulfilment. Never give any agent a key with more permissions than it needs — and rotate on personnel changes.
wp-json path can be customised
Some WordPress installs change the REST prefix (security through obscurity). Hit https://store.com/wp-json/ first to confirm the discovery endpoint resolves.
v3 requires WooCommerce ≥ 3.5. Check GET /wp-json/wc/v3 returns 200 before assuming any endpoint exists — older installs will surprise you.
Unlike the other ERP leaves, woocommerce's canonical skill declares no hard requires — it runs independently. But it still sits inside the tree and compounds with its neighbours.
improves biz/erp — contributes the plugin-aware operations playbook back to the shared ERP skill.The official REST docs are the source of truth for endpoint shapes. The canonical SKILL.md has the opinionated patterns, failure modes, and the role model.