Headless Commerce Explained

What is headless commerce?

In a traditional ("monolithic") eCommerce platform, the same system stores products, handles carts and orders and renders the pages shoppers see, usually through a theme. Headless commerce separates those two jobs. The commerce engine (the "body") exposes products, prices, carts, checkout and customers through APIs, and a separate front end (the "head") calls those APIs to build the storefront.

Because the front end is independent, it can be built with any web framework, deployed separately, and reused across channels such as a website, a mobile app, in-store screens or a marketplace feed, all drawing on the same commerce back end.

A typical headless architecture

The front end usually renders pages on the server or at build time (SSR or static generation) so that product and category pages load fast and are fully indexable, then hydrates interactive parts such as variant pickers and the cart in the browser.

Headless, composable and MACH

The terms are related but not identical:

• Headless only means the front end is decoupled from the back end.
• Composable commerce goes further: instead of one platform, you assemble best-of-breed services (commerce engine, CMS, search, PIM, payments) that each do one job.
• MACH stands for Microservices, API-first, Cloud-native and Headless, a set of architecture principles promoted by the MACH Alliance industry group.

You can run a headless front end on a conventional platform such as Shopify or Adobe Commerce without going fully composable, and that is often the pragmatic first step.

Advantages

• Front-end freedom: complete control of design and UX, not constrained by theme templates.
• Performance potential: modern frameworks, edge rendering and fine-grained caching can produce very fast pages, if the team builds for it.
• Omnichannel reuse: one commerce API serves web, apps, kiosks and partners.
• Independent releases: front-end teams ship without touching the commerce back end, and vice versa.
• Swappable components: replace search or CMS without replatforming everything.

Drawbacks and hidden costs

• More to build: features a theme gives you for free (account pages, search results, filters, SEO tags, sitemaps, previews for editors) must be built and maintained.
• More vendors and contracts: several services means several bills, SLAs and integrations to monitor.
• Apps and plugins may not work: many platform apps inject code into themes and do not support headless storefronts.
• Need for a capable team: you need developers comfortable with the framework, APIs, caching and DevOps, long after launch.
• Performance is not automatic: a heavy client-side JavaScript front end can be slower than a good theme.

When headless makes sense

Headless is usually worth it when several of these are true:

• You sell through several front ends (web, app, in-store, B2B portal) that should share one commerce back end.
• Your content and storytelling needs exceed what the platform's theme editor can do.
• You have, or will fund, an in-house or partner development team for ongoing work.
• You have specific performance, internationalisation or UX requirements the theme layer blocks.

It is usually not worth it for a new or small store with a standard catalogue: a well-built theme on a hosted platform will launch faster and cost less to run. Compare options in our platform comparison and model the running costs with the cost calculator.

Platform options for headless

• Shopify: Storefront API plus the Hydrogen framework and Oxygen hosting; checkout remains Shopify-hosted.
• BigCommerce: GraphQL Storefront API and an open-source Next.js starter (Catalyst).
• Adobe Commerce / Magento Open Source: GraphQL API, with PWA Studio or third-party front ends.
• commercetools: API-only commerce platform built for composable setups.
• Open-source engines: Medusa, Saleor and Vendure, which you host yourself.