Latest features: the agentic storefront
- Version
- 3.x
- Updated
Your customers' AI assistants can now shop your store. Not a chatbot bolted onto the page — a headless surface where the assistant a customer already uses browses your catalog, configures a product through its real rules, watches the price move, and fills their cart. Over the Model Context Protocol, with no browser and no rendered page anywhere in the loop.
It is one endpoint. A customer points their assistant at https://your-store/cbx-api/mcp, signs in
once in their own browser, approves what the assistant may do, and from then on they can say "find me
a linear luminaire for a 24-foot run, 4000K, and put it in my cart."
Why this is different from a chatbot
CBX already has an AI advisor beside the configurator — a panel on your storefront, your model, your prompt, your bill. That is a feature of your store.
This is the other direction. The customer brings their own assistant, in whatever surface they already work in, and your store is one of the tools it can reach. You pay for no inference. You prompt no model. Your store is the thing being used, not the thing doing the using — which is exactly why the guarantees below sit in the data and the permission layer rather than in a prompt.
| The chat advisor | The agentic storefront | |
|---|---|---|
| Where it runs | your storefront page | the customer's own assistant |
| Who pays for the model | you | the customer |
| Who controls the prompt | you | not you — so nothing may depend on it |
| What it is | a feature of your store | your store as a capability of theirs |
What an assistant can actually do
Fifteen typed tools — not an API a model has to be described in prose, but real tools with real schemas it can call:
- Browse the configurable catalog, with prices as that customer's group sees them.
- Configure a product: start it, answer questions, get the running price, and ask why an option is unavailable — the rule taken apart into its conditions and what would satisfy them.
- Preview a choice before committing: what the price would become and which questions would open or close, changing nothing.
- Work the cart: add, change quantity, copy a line ("the same again but in blue"), reopen one for editing, remove, save the cart for later — and hand the customer a URL to open it in your shop.
Checkout is deliberately not in this set. The assistant takes the customer to the point of paying and gives them the link; addresses, delivery and payment stay on your pages.
The part that matters: it configures correctly
A product configurator is not a catalog with a shopping cart. Answers interact — choosing a direct luminaire makes every indirect lumen output, colour temperature and lens impossible — and an assistant that does not keep up will confidently offer a customer something the rules already ruled out.
CBX solves this in the surface itself, not in prompt advice:
The rules run for real. Every selection goes through the same engine, the same validation and the same recalculation the browser storefront uses. There is no second implementation to drift.
Availability is re-readable cheaply. After each selection an assistant can ask what is still selectable and get back just that — the answers that remain, and the ones that no longer do. On a real 21-question product that costs 9.5 kB where re-reading the product structure costs 100.8 kB. That ten-fold difference is the whole feature: a re-read that expensive is one an assistant will skip, and skipping it is precisely how it ends up offering the impossible.
When something is refused, the refusal explains itself. Not "invalid selection" — the governing rule, which of its conditions currently fail, and the selections that would satisfy them. An assistant can course-correct without a human in the loop.
Pricing stays yours
Pricing in CBX is a customer-group property, and the agentic surface inherits it whole. Every tool call runs as one specific customer, so their group's pricing simply applies:
- A customer whose group may not see prices gets the same tools with the price keys absent — not zeroed, absent. There is nothing to leak and nothing to argue a model out of.
- Per-product price switches (show the total but not what each option adds) are honoured identically.
- B2B net-price mode is honoured identically.
This is a data guarantee, not a prompt guarantee. That distinction is the point: a rule in a prompt is a suggestion a determined visitor can talk a model out of. A figure that was never sent cannot be leaked, whatever anyone says to the model.
Consent, and the customer's off switch
Access is OAuth 2.1 — the standard the MCP authorization spec names, implemented properly rather than approximated:
- The store hosts its own authorization server, because CBX is platform-neutral and none of its
hosts ships one to borrow. Clients discover it: the
401names the metadata document, which names the server, which names the endpoints. - PKCE is mandatory (S256), redirect URIs are matched exactly (no open redirect),
stateis round-tripped, and a per-request nonce guards the consent step against CSRF. - Access tokens are short-lived; refresh tokens rotate on use. Both are opaque and stored server-side, so revocation is immediate rather than eventual.
- Tokens are audience-restricted to your MCP endpoint and the server checks it — an agent cannot bring a token minted for somebody else's store.
- Clients register themselves (RFC 7591). The assistant never sees the customer's password: they sign in and consent in their own browser.
And then the half that customers actually feel — on their account page:
- Connected assistants: which agents hold access, and since when.
- Recent activity, in their words, not the tool's: "Chose an option", "Added a configuration to the cart". Reads are logged too — "it looked at my prices" is exactly the kind of thing a person may want to see.
- Turn off, which bites on that assistant's very next call.
Why you can trust it with a customer's account
A standing credential that acts as one customer is a serious thing to hand out, and the design treats it that way.
Isolation is bidirectional and absolute. A shopping token holds storefront scopes or back-office scopes — never both, enforced when the token is minted. A customer's assistant is never even offered the tools that read your catalog internals, your other customers, or your settings; and a back-office token never sees the shopping tools. Neither is a subset of the other. Without this rule a token acting as one customer could read every customer's data — the classic confused-deputy hole, foreclosed by construction rather than patched.
Ownership is re-checked on every single call. A cart or configuration belonging to someone else is refused, not merely hidden.
And it has been driven hard, not just written. The guarantees above are pinned by an automated suite, and several of them exist because driving the surface as a real client broke it first:
- Nine different cross-customer attacks — reading, writing, saving, removing, copying, reopening and re-pricing another customer's things — all refused.
- The price gate walked across eleven tools, reads and writes alike, and mutation-verified: deliberately breaking the gate makes the test fail. A leak test that has never failed proves nothing.
- Two statefulness bugs found and fixed — both of which reported success while doing nothing, the worst shape a bug can take. Their tests now read back in a later request, because a spec that trusted the write's own response passed against the broken build.
- A tool result that came back empty is now reported as an error rather than as a success, because an assistant reads "success with nothing" as "it worked" and builds on it.
That record is offered deliberately. Anyone can list features; what should persuade you is that the surface was attacked, measured and corrected before it was documented.
Getting started
- It is already there. The endpoint ships with CBX; there is nothing to install.
- Give a customer the URL —
https://your-store/cbx-api/mcp— and their assistant does the rest. - For your own integrations, mint a token directly:
configbox:token:mint "Concierge bot" --scope=storefront:write --for-customer=1234.