Headless Commerce
Headless commerce is an architectural approach to online retail in which the presentation layer (the "frontend", the shop customers see) is technically decoupled from the commerce backend (cart, prices, orders). The two layers communicate exclusively through an API, letting sales channels be designed freely and evolve independently of the backend.
Headless commerce describes an e-commerce architecture in which the frontend – the user interface customers shop through – is completely separated from the backend that manages the actual commerce logic such as catalog, prices, cart and orders. The term "headless" refers to exactly this separation: the commerce system is stripped of its "head", the fixed presentation layer. Instead, frontend and backend exchange their data through a programming interface (API). The backend delivers product data and functions as data packages, and the frontend decides freely how and where they are displayed.
The practical effect: a company can deliver the shopping experience on any channel it likes – in a web shop, in an app, on a marketplace, on an in-store POS terminal or even on a voice assistant – while always using the same backend. Because both layers can be developed further and swapped out independently of each other, retailers gain design freedom and speed. Headless commerce thus stands in contrast to the classic "monolithic" shop system, in which design and commerce logic are tightly interwoven.
At a glance
- Separation of frontend (presentation) and backend (commerce logic) – connected only through an API
- One backend serves any number of channels: web, app, marketplace, POS, IoT
- Frontend freely chosen and quickly changed without touching the backend
- Counter-model to the monolithic shop system with a hard-wired interface
- Downside: higher technical complexity, more development effort and building blocks
How does headless commerce work?
At its core, headless commerce splits the system into two independent parts. The backend – often called the "commerce engine" – holds the entire commerce logic: the product catalog with prices and stock, the cart and checkout functions, customer and order data, as well as the connection to payment providers and downstream systems. It no longer has a sales interface of its own. Everything it can do, it makes available through an API.
The frontend is a separate application that talks to this API. When a customer opens a product page, the frontend requests the relevant data from the backend – title, image, price, availability – and renders it in its own design. When the customer adds something to the cart, the frontend sends this action via API to the backend, which manages the cart and reports back. Because communication runs in a standardized way through the interface, the backend does not care whether the request comes from a web shop, a mobile app or a completely different channel.
Frontend, backend and the API in between
The API is the connecting element and at the same time the real lever of the approach. It defines a fixed contract about which data and functions the backend offers – for example "give me product X" or "add item Y to the cart". As long as this contract stays stable, frontend and backend can be rebuilt independently of each other: marketing can completely renew the design without touching the commerce logic, and IT can scale or replace the backend without touching the frontend. REST APIs are common here, and increasingly GraphQL APIs as well.
Building blocks of a headless architecture
A headless setup rarely consists of a single product, but rather of several specialized building blocks that interact through APIs. The core is formed by the commerce engine for catalog, prices, cart and checkout. For the frontend, a dedicated framework is often used – for instance based on modern JavaScript technologies – that delivers the pages quickly and in a search-engine-friendly way.
The core is complemented by further systems: a PIM manages product information centrally and delivers it to the engine, a content management system (often as a "headless CMS") controls editorial content, and payment and shipping services attach as their own services. This decomposition into interchangeable, API-connected services is characteristic of the modern, "composable" way of thinking about commerce: each building block can be selected, improved or replaced individually, instead of being tied to one rigid, all-in-one block.
Why headless commerce? Benefits and limits
The most important benefit of headless commerce is flexibility. Because the frontend is freely designable, brand and shopping experiences can be implemented that a rigid shop template cannot deliver – and across many channels from a shared data source. New touchpoints such as apps, marketplaces or in-store displays are connected without duplicating the commerce logic. On top of that comes speed: frontend teams and backend teams work in parallel and independently, and design changes go live faster. Performance also benefits, since frontends can be optimized specifically for load time and SEO.
These advantages come at the cost of higher effort. A headless build is more technically demanding: instead of a ready-made complete package, the frontend must be developed and maintained independently, and several systems have to be integrated and operated through APIs. This requires developer know-how and a well-thought-out interplay of the building blocks. For a small standard shop, the approach is often oversized – here a classic shop system is enough. Headless unfolds its full potential where many channels, individual experiences or high scalability are required.
When headless pays off – and when it does not
As a rule of thumb: the more individual the frontend, the more sales channels and the higher the demands on performance and scaling, the more headless commerce pays off. Large retailers, brands with a strong design ambition and international multichannel players are typical candidates. Conversely, a small retailer with a manageable range and one channel is usually cheaper and faster off with a monolithic standard shop – they would pay dearly for the freedom of the headless approach with complexity and ongoing development costs.
Headless commerce and the ERP system
For the ERP system, headless commerce changes one thing above all: the point of contact shifts from the shop to the API. Even in classic retail, the ERP is the leading source for item master data, prices, stock and orders – in a headless setup this remains unchanged, except that this data is no longer handed over to a monolithic shop system but to the commerce engine, which distributes it from there via API to any number of frontends. The ERP remains the central hub for inventory management and commercial processes.
Concretely, orders from all headless channels flow back into a unified order processing in the ERP, while the ERP reports current stock and prices to the commerce engine. Because everything runs through interfaces anyway, the API-first idea of headless fits well with ERP systems that themselves bring open APIs. For retailers, it is crucial that the integration is set up cleanly: stock must stay synchronized across channels so that even with many frontends no overselling occurs – a classic task of the ERP as the single source of truth.
Distinctions: headless, monolith, MACH and composable commerce
The counter-concept to headless is the monolithic or "full-stack" shop system, in which frontend and backend are delivered as one inseparable unit. Such systems are quick to get running and low-maintenance, but they limit the design freedom of the frontend. Headless dissolves this coupling – but buys that freedom with more integration effort.
Around headless, further terms have become established. "MACH" stands for microservices, API-first, cloud-native and headless, and describes an architectural principle that includes headless as one of four building blocks. "Composable commerce" means building the entire commerce landscape from interchangeable best-of-breed components that are plugged together via API – headless is the technical prerequisite for the decoupled frontend. Put simply: headless describes the separation of head and body, MACH the overarching architectural pattern and composable the free assembly of the building blocks. All three aim at the same basic idea – flexibility through loosely coupled, API-connected systems instead of one rigid block.
Example
Example: a brand moves from monolith to headless
A growing manufacturer of cosmetics products ran its online shop on a monolithic standard system. As long as only the web shop was served, that was enough. With expansion came a mobile app, several campaign landing pages and in-store tablets in the first company-owned stores. Each of these interfaces needed the same product data, prices and stock – but the monolithic system could only serve its own shop. The team maintained content multiple times and constantly ran into the limits of the template with individual design requests.
The brand switched to a headless architecture. A commerce engine took over catalog, cart and checkout and makes everything available via API; a dedicated, fast frontend has since delivered the web shop, and the same API supplies the app and store tablets. The ERP remained the leading system for item master data, stock and orders and reports its data to the engine, while all orders converge centrally across channels. The result: a unified brand experience across all channels, significantly shorter implementation times for new frontends – and stock that stays synchronized despite many touchpoints.
Frequently asked questions
Related services
Questions about Headless Commerce in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.