What is Headless Commerce?
Definition
Headless commerce is an ecommerce architecture in which the customer-facing storefront is decoupled from the commerce engine that manages products, pricing, inventory, carts and orders. The engine exposes its functions through APIs, so a website, a mobile app or an in-store screen can all draw on the same backend while each front end is built and released independently.
Also known as: headless ecommerce, decoupled commerce, API-first commerce, headless storefront

Splitting the storefront from the engine
In a traditional ecommerce platform the catalogue, pricing rules, cart, order management and customer-facing templates all live in one application. Even a redesign happens inside the platform's theme language. Headless commerce cuts that monolith in two. The back end keeps the commerce engine, which owns catalogue data, stock, promotions, carts and orders, and exposes all of it only through an API. The storefront becomes a separate application: a React or Next.js site, a native app or a kiosk in a physical shop, all reading from the same engine.
The idea mirrors a headless CMS, with one important difference: a commerce engine carries far more state and business logic than a content repository. Stock reservations, tax, shipping, payments and returns all sit behind that API. That is why the hard part of a headless project is rarely the front end itself; it is designing a clean contract between the storefront and the engine.
What happens when a product page loads
When a shopper opens a product page, the storefront asks the engine for the title, price, variants and availability, renders the HTML and sends it to the browser. Adding to cart, applying a coupon and starting checkout are further calls to the same API. Many engines offer a GraphQL endpoint alongside REST, so the storefront can request exactly the fields it needs in one round trip:
query Product($handle: String!) {
product(handle: $handle) {
title
variants(first: 10) {
nodes { sku availableForSale price { amount currencyCode } }
}
}
}Field names differ between platforms; the query only illustrates the shape. When a price changes or an item sells out, the engine can fire a webhook that tells the storefront to rebuild or purge the affected cached pages. Skip that loop and the site may show stale prices for hours.
What you gain, and what it really costs
- Freedom over the experience: the storefront is built with whatever stack and design the team chooses, not what a theme allows.
- One engine, many channels: web, app and marketplace integrations share one catalogue and one stock count.
- Independent releases: front-end developers can ship without touching payment or order logic.
The costs are just as concrete. You now host, monitor and version two systems. Features a theme gives you for free, such as on-site search, filters, account pages, order tracking and promotional slots, have to be rebuilt in the storefront. Many platform apps and plugins only inject into the classic theme, so their functionality has to be re-integrated at the API level. For a small shop with standard flows, the extra complexity rarely pays for itself.
SEO work that no longer comes built in
Going headless is neither good nor bad for search by itself; what matters is how the storefront renders. If product and category pages are assembled only by JavaScript in the browser, you inherit the usual JavaScript SEO risks: an empty initial HTML response, links that appear late, and indexing that waits on rendering. Commercial pages are therefore usually delivered with server-side rendering or static generation. You also have to rebuild what the old platform generated automatically:
- unique titles, meta descriptions and canonical tags for every product and category;
- Product and breadcrumb structured data;
- an XML sitemap, plus permanent redirects for every legacy URL;
- correct status codes for discontinued products.
Moving an existing store to a headless setup is also a site migration. Launch without a URL mapping and established rankings can disappear.
Headless versus composable
Headless commerce decouples only the presentation layer; the engine can still be a single platform. Composable commerce goes further and assembles search, payments, content, pricing and order management from separate, swappable services. Every composable stack is headless, but not every headless build is composable. The right level depends on team size, the number of sales channels and how complex the catalogue is, not on what is fashionable.

