definition

What is headless commerce?

Headless commerce separates the storefront UI from the commerce backend, so the two halves talk through APIs instead of being shipped together as one template-driven application. The pattern is useful when a manufacturer needs a custom frontend, a multi-channel experience, or a release cadence the platform's templating engine cannot accommodate. It does not, on its own, solve backend or integration problems.

Frontend & backend separation, explained

In a traditional commerce platform, the storefront and the commerce engine are one application. The platform renders pages from templates, with the commerce logic and the UI living in the same codebase. A headless build keeps the commerce engine intact and replaces the storefront with a separate application that calls the engine through APIs.

The frontend is then free to be anything the team wants: a Next.js app, a React Native mobile app, a kiosk client, a customer portal, even an in-store screen. All of them talk to the same commerce backend through the same APIs. The backend continues to own carts, orders, inventory, and customer records; the frontend owns the experience.

Platforms support this differently. Some, like BigCommerce, expose a thorough Storefront API and explicitly support headless from day one. Others, like Shopify, ship a dedicated frontend framework (Hydrogen) for the pattern. Others again, like Shopware, expose the commerce engine through a Sales Channel API and let the team pick its own frontend stack. The common thread is the API boundary between the storefront and the engine.

What headless does and does not include

Headless includes: a custom frontend, full control over markup and rendering, the ability to deploy frontend changes independently of platform releases, and the option to share one commerce backend across multiple channels. It also includes the engineering responsibility for everything the platform's templating layer used to handle automatically, including SEO, accessibility, internationalization, and structured data.

Headless does not include a new backend. It does not include a new pricing engine. It does not include a new integration with the ERP. If your business logic is straining a monolithic platform's defaults, headless will not relieve that strain. It will leave the backend exactly as it was and move the storefront into a separate codebase, which the team now has to maintain alongside the platform itself.

That gap (headless changes the frontend, not the backend) is the most consistent misunderstanding we see in B2B projects. A manufacturer with pricing problems is often pointed at a headless build by a frontend agency because that is the work the agency does. The pricing problem persists, the project costs more, and the team is now running two codebases. The decision to go headless is worth pressure-testing against where the actual pain lives.

BigCommerce headless and Shopify headless as examples

BigCommerce has supported headless as a first-class pattern for years. The Storefront API exposes catalogue, cart, checkout, customer, and order data, and the project is free to render however the team chooses. The native Stencil template engine remains an option for teams that do not need the flexibility. The BigCommerce headless article covers the B2B-specific decision in detail.

Shopify's version is more opinionated. Hydrogen is Shopify's React-based framework for headless storefronts, paired with Oxygen, Shopify's hosting platform for it. The pattern works well for teams committed to the Shopify ecosystem and willing to adopt Shopify's frontend conventions. It works less well when the team needs the freedom to choose a non-Shopify frontend stack or to host the storefront elsewhere. The Shopify headless article walks through the B2B trade-offs.

Both patterns are headless. Neither is composable. A BigCommerce headless build still uses BigCommerce for catalogue, cart, and checkout. A Hydrogen build still uses Shopify for the same. The frontend is independent; the rest of the stack is not. That distinction matters for the next architecture conversation.

Why headless is not the same as composable

Headless changes the frontend. Composable changes the entire stack. A headless build keeps the platform's commerce engine and swaps the storefront. A composable build assembles a stack from independent services: separate cart, separate search, separate CMS, separate identity, all glued together with APIs.

A team can go headless without going composable, and many do. The combination of "platform commerce backend + custom decoupled frontend" is a stable, defensible pattern for B2B manufacturers who need experience flexibility without taking on the operational cost of running every service separately. It is the pattern most augmented builds end up using.

Composable is the next step beyond headless, and the cost curve gets steep. The decoupled vs headless vs composable article compares the three patterns directly. If the frontend is the main pain point, headless is usually enough. If the backend itself does not fit, that is when the composable conversation becomes a real conversation.

Common B2B use cases where headless adds value

The patterns where headless earns its keep in B2B: a manufacturer running multiple regional storefronts on one commerce backend with different brand expressions; a dealer portal that needs a very different UX from the public catalogue; a customer with strict performance or accessibility targets that the platform's default templates cannot meet; a team that needs a faster release cadence than the platform's template releases allow.

Headless is also a good fit when the frontend has to host non-commerce content alongside commerce, like long-form technical documentation, configurators, or marketing campaigns built in a separate CMS. The frontend becomes the place where commerce data and content data meet, and the platform's templating engine is not the right tool to hold both.

Where headless tends to disappoint: a single-channel storefront with a stable template, a small team without dedicated frontend engineering, or a project whose actual pain is integration rather than experience. In those cases, the operational cost of running a separate frontend application outweighs the gain. The platform's templates were doing more useful work than they got credit for.

Frequently Asked Questions

Next Step

Get the foundation right before you build.

For readers scoping a platform decision or wanting a full architecture recommendation.