"Headless" is one of those words that arrived fully formed and slightly overheated. Vendors put it on everything. Buyers nod. Six months later someone asks what it changed, and the honest answer is sometimes "the invoice".
So here is the plain version, what it is genuinely good for, and the question worth asking before you buy it.
What it means
A traditional commerce platform ships two things welded together: the engine that knows about products, prices, carts and orders, and the storefront that renders them. You get a theme, you edit it, and the shape of your site is the shape the platform expects.
Headless separates them. The engine exposes an API — catalogue, cart, checkout, orders — and the storefront becomes your problem, in whatever technology you like. The "head" is the front end; removing it is the whole metaphor.
That is it. Everything else is consequence.
What it actually buys you
More than one front end over one catalogue. This is the real reason most organisations end up here. A brand site, a mobile app, an in-store kiosk, a partner's own storefront, a marketplace listing — all reading one range, one price book, one stock position. The alternative is synchronising several systems, which is a job that is never finished.
Front-end change without back-end risk. Marketing rebuilds the product page; nobody touches the pricing engine. The blast radius of a redesign stops at the API boundary.
Rendering you control. Performance, accessibility, and the specific interaction your category needs — a configurator, a serviceability check, a scheme calculator — are yours to build rather than yours to request.
What it costs
The costs are real and are usually understated in the sales conversation.
You now own a front end. Not a theme — an application, with a deployment pipeline, a dependency tree, a security posture and an on-call rota. Organisations that were happy editing a template are frequently unhappy owning a codebase.
Someone has to decide what the API is allowed to say. A public storefront endpoint is an anonymous, internet-facing read path into your commercial data. Which fields? Which prices, for whom? What stops a competitor crawling your entire range and price book at leisure? These are policy questions, and headless makes them explicit rather than answering them for you.
Consistency becomes a discipline. When one team renders the cart and another computes it, the two can disagree. The classic version of this bug is a front end that recomputes a total "to avoid a round trip" and slowly drifts from the engine's arithmetic — until a customer is charged something other than the number they were shown.
The question worth asking
Not "is it headless" but "where does the money maths happen".
If the answer is "in the front end, mostly, for speed", you have bought a distributed system with two sources of commercial truth and no referee. Every discount rule, tax rule and scheme now exists twice, and they will diverge — not immediately, but on the day someone changes one and forgets the other.
The answer you want is that the engine prices and the front end renders. Every rupee comes from one place; the storefront's job is to display what the priced basket says and nothing more. That constraint sounds limiting until the first time someone changes a tax rule and the site simply reflects it.
How xMatix does it
xMatix is API-first for commerce, with two deliberate constraints.
The first is that the storefront reads a published catalogue, not the live item master. Publishing builds an immutable, versioned projection of a store's range and flips it live in one step. Anonymous traffic — which is unpredictable and frequently bot-driven — never touches the operational tables, so a crawl cannot slow the system your staff are using, and a half-finished merchandising change cannot leak. Product URLs are assigned once and never reused, so links stay valid across republishes.
The second is that pricing has exactly one implementation. Cart totals are produced by the same routine that computes a sales order line — literally the same code path, not a parallel one kept in step by convention. A cart cannot disagree with the order it becomes, because there is nothing to disagree with.
Around that sit the parts a real integration needs: keyed and origin-restricted access for each consumer, signed outbound events so your systems learn about orders and payments without polling, deduplication by event id, and retry with backoff when your endpoint is having a bad afternoon.
And the part people forget
A headless order still has to be fulfilled. It needs allocating, picking, invoicing and collecting; someone has to answer the phone about it; the finance team has to recognise the revenue.
This is where a commerce-only engine leaves you with the second integration project — the one that was not in the plan, connecting orders to the system that actually runs the business. In xMatix a consumer order is an ordinary sales order the moment it is placed: same document, same lifecycle, same reports, same mobile app, same security model. The channel tells you where it came from. It does not put it somewhere else.
Which is the useful test for any headless proposal. Ask what happens to the order after checkout succeeds — and count the systems in the answer.