The dashboard is a client. Your code gets the same API.
Anything Cascade can do from a screen, your code can do from a request. That is not a roadmap item, it is how the product is built.
The API: everything the dashboard does
GET /reviews?filter={"rating":{"$gte":4}}
POST /loyalty-events
GET /wishlists?include="items"
POST /analytics/queryOne surface, no second-class citizens.
An API bolted onto a product drifts behind it. An API the product runs on cannot.
- Everything the dashboard does
- Reviews, loyalty, referrals, wishlists, customers, orders, products, analytics: one REST API covers all of it, because the dashboard itself is built on it.
- One filter language
- List endpoints take the same JSON filter document the dashboard's filter bars produce, so a filter you build on a screen is a filter your code can run verbatim.
- A typed client
- The @cascade-commerce/api package is generated from the same OpenAPI documents as the reference docs, so your editor knows every route, parameter and response shape.
- Webhooks
- Changes push back to you as they happen, so a review published in the dashboard reaches your systems without polling.
- CSV in, CSV out
- Products, customers, orders, reviews and loyalty history all import from CSV and export back to it. Rows that cannot be resolved are skipped and reported with line numbers, not fatal.
- Published rate limits
- One organization-wide ceiling, documented, with a Retry-After header when you hit it. No guessing at invisible quotas.
Keys you can hand to a contractor without holding your breath.
Access control is the part of an API you only notice when it is missing. Cascade's is explicit everywhere.
- Scoped secret keys: twelve resource groups, each with separate read and write, so a key holds exactly the twenty-four-scope subset it needs and a 403 names the missing permission.
- Write does not imply read, and every admin route declares the scope it checks. The key edit screen shows the same checklist the API enforces.
- Keys carry optional expiry presets and rotate without downtime, and an IP allowlist in CIDR form pins a key to the machines that should hold it.
- OAuth 2.1 with PKCE for user-facing integrations, using the same scope vocabulary as secret keys rather than a second one to learn.
Your AI tools can drive it too.
Cascade ships an MCP server, so Claude and any other MCP client can read and act on your store with your permission.
Connect from claude.ai with OAuth and no installation, or run the local binary with a secret key from Claude Code or Cursor. Either way, every tool call goes through the same documented API with the credentials you granted, so an agent can never do more than the key or token it holds.
Writes are off unless you turn them on. An agent that should only ever read your store stays an agent that only reads your store.
Remote, from any MCP client
https://api.cascade.example/mcp
# OAuth 2.1, scopes you approveLocal, with a secret key
CASCADE_API_KEY=sk_live_9f2c \
cascade-mcpThe rest of Cascade.
Every feature runs on the same customer record and the same REST API, so each one you turn on makes the others worth more.