Headless commerce is an ecommerce architecture in which the storefront — the pages a customer sees — is built and deployed as a separate application from the commerce backend that owns catalog, cart, checkout, and orders, with the two communicating over APIs. The contrast case is a templated storefront, where the frontend runs inside the backend’s own runtime; a Shopify theme rendered by Shopify is the modal example. A headless setup replaces that theme with a separately built application that calls the backend’s APIs for product data and checkout.
The case for headless rests on three things. A well-built headless storefront can outperform a templated one on Core Web Vitals, though performance ultimately depends on implementation quality, not architecture alone. Design is no longer constrained by what a theme will tolerate. And one backend can serve multiple frontends — web, native app, in-store kiosk, marketplace listing — without forking the catalog.
The case against is equally concrete. Third-party apps that ship as theme extensions — reviews widgets, upsell modules, subscription managers — have to be re-integrated against the headless frontend or replaced. Build and maintenance cost is materially higher. And tracking, which a templated storefront mostly inherits from the platform, becomes the brand’s responsibility to wire end-to-end.
That last point is the one operators routinely underweight. A headless storefront has to forward its own events to ad platforms and analytics destinations explicitly, where a templated theme would have done much of it through the platform’s built-in tracking. The data being forwarded is the brand’s first-party data, and the quality of that wiring sets the ceiling on downstream attribution.
Composable commerce extends the same API-first decoupling beyond the storefront/backend split to the broader stack — search, payments, loyalty, OMS — assembled from best-of-breed services. Headless is the storefront-layer instance of that pattern.