Latest features
- Version
- 4.0 preview
- Updated
What has landed in CBX since the 4.0 line opened — the work of July and August 2026, across every surface the product has: the storefront and the configurator, the admin, the HTTP API, the CLI, the MCP server, the AI assistant, payments, catalog operations and the extension layer.
This is part of the Features track, and it keeps that track's one hard rule: every claim below links to the documentation that describes it in full. A claim with no link is a bug in this page.
Looking for the upgrade story instead? "What's new" in the sense of CBX 2/3 → CBX 4 — the answer-model collapse, the renames, what breaks and what it costs — is a different question with its own set of pages: for decision makers · for operators · for developers. This page is what has been built since that line opened.
The nine areas
| Area | What changed |
|---|---|
| Configurator & storefront | An AI advisor beside the configurator, a reactive client store, an honest checkout, readiness signals a test can wait on |
| The admin | Dark mode, on-screen help, one save path, and screens for API tokens, product transfer, payments and the assistant's journal |
| The HTTP API | A token-authenticated REST surface over the whole catalog, described by OpenAPI 3.1, plus a runtime API that configures a product without a browser |
| The CLI | The configbox:* suite on all three hosts, deploy gates that exit non-zero, and a custom namespace for site-specific commands |
| The MCP server | Typed tools that let an AI assistant read, author and operate a store — over stdio or over HTTP with a scoped token |
| The AI assistant | The configurator chat advisor: it acts through the same API the page uses, journals everything, and files what it could not do |
| Payments & commerce | A payment subsystem designed from requirements: a ledger, a state machine, fourteen providers, a poll command |
| Catalog operations | Move a product between installs, delete one and its whole graph, copy one and control what travels |
| Platform & extensibility | Generated record classes and schemas, prepared statements, exceptions, and what the customization layer learned to extend |
If you only read one screenful
-
Your catalog now has a programmable surface.
GET/POST/PATCH/DELETE/cb-api/v1/{entity}covers every registered entity, authenticated with bearer tokens whose scopes are<area>:<level>— so an integration can be given orders without the catalog. The OpenAPI 3.1 document, Postman collection and browsable HTML reference are generated from the models themselves, so they cannot describe fields that do not exist. → The HTTP API -
An AI assistant can operate the product — as a shopper, as an author, and as an operator. The chat advisor sits beside the configurator and makes selections in the visitor's own session; the MCP server lets an assistant build products, write rules, author calculations and run admin operations — over stdio, or over HTTP with a scoped token. Everything runs the same validation an admin form runs.
-
Operations got real tooling.
configbox:migrate --statusexits non-zero while schema work is pending, so a deploy can gate on it; settings, tokens, types, orphaned strings, payments polling and product transfer all have commands; the whole suite runs on Joomla, WordPress and Magento 2 from one shared core. -
Taking money is a subsystem now, not a folder of connectors. A payment ledger, an explicit state machine, settlement by return / webhook / poll, an admin ledger UI and a roster of fourteen providers — with each provider's verification status stated plainly rather than implied.
-
A product can move, and a product can go. Product transfer packages a product's whole graph — pages, questions, answers, panes, rules, calculations, images — validates the package before writing anything, and re-aims every reference on arrival. Deleting one is the same graph in reverse: behind a typed confirmation, and refused if anything outside the product still needs a piece of it.
How this page is maintained
Same rule as the rest of the Features track: a capability earns a line here once it has landed and once it is documented, and the line carries the link. Work that is built but not yet merged, or merged but not yet described anywhere, waits. Where something is shipped but unverified — several payment providers are wired against a documented API but have never seen live credentials — this page says so rather than rounding it up.
Last reviewed: 2026-08-24.