How Does Headless Commerce Work, and Is It Right for Your Store?

Headless commerce works by splitting your online store into two programs that talk through APIs. One is the storefront your shoppers see. The other is the commerce back end that runs products, carts, checkout and orders. It suits a store whose theme blocks what the business needs and that can pay developers long after launch.

Most stores selling a standard catalog in one or two markets get more from a better theme. The question comes up when a theme starts to feel tight: a designer wants a product page it can't produce, or a mobile app is on next year's plan.

On this page

• What is headless commerce?
• How headless commerce works, one page view at a time
• Headless vs traditional ecommerce, side by side
• How a headless Shopify store fits together
• What changed in Shopify Hydrogen in October 2026
• What does headless commerce cost to build and run?
• Will a headless rebuild pay for itself?
• Pros and cons of going headless
• Is a headless store faster than a theme?
• Which stores gain from headless commerce
• Lighter options before a full rebuild
• What to settle before you commit

What is headless commerce?

Headless commerce, also called headless ecommerce, is a store setup where the storefront and the commerce engine run as separate programs. The "head" is the presentation layer a platform normally builds for you. On Shopify, that's the theme. It's written in Liquid, Shopify's template language, and Shopify renders and hosts every page.

Going headless removes that layer and puts your own front end in its place. The back end keeps doing the jobs it always did: catalog, inventory, payments and order records.

How headless commerce works, one page view at a time

In a headless store, the back end is the commerce platform: Shopify, BigCommerce or another engine that stores the catalog, runs the cart, takes payment and records the order. The front end is a separate web app your developers build in a framework such as React Router or Next.js. Follow one shopper through it:

1. A shopper opens a product page, and the request goes to your front end rather than to the commerce platform.
2. The front end asks the platform's API for that product's title, images, variants, price and stock. On Shopify this is the Storefront API, which only speaks GraphQL, a query format where the front end names the exact fields it wants back.
3. Your app builds the page in whatever layout your designer chose and sends it to the browser.
4. The shopper taps "Add to cart." The front end passes that to the API, and the platform keeps the cart.
5. At checkout, the shopper moves to the platform's own checkout, which takes payment and creates the order in the admin your team already uses.

Content that isn't product data, such as lookbooks, buying guides and campaign pages, lives in a content management system (CMS) that the front end also calls. If those pages sit on an old PHP site today, moving them is its own project, a PHP to headless CMS migration.

Because neither side depends on the other's code, you can redesign the storefront without touching how orders get processed.

Headless vs traditional ecommerce, side by side

A theme store and a headless store can run on the same commerce engine. They differ in who builds and hosts the pages. A partial build sits between the two.

Read the table from left to right. Every column you move across adds a job that someone on your payroll or retainer has to cover.

How a headless Shopify store fits together

Shopify's headless documentation sums it up in two lines: you build the frontend, and Shopify's APIs handle the commerce underneath. A headless Shopify store picks from the parts below, and few stores need all of them.

The Storefront API does most of the work. It serves products, collections, search and the cart, then hands the shopper to Shopify's checkout. Requests from real buyers aren't held to a fixed per-minute limit, though bots and checkout creation are throttled. Its partner, the Customer Account API, handles sign-in and gives the front end each customer's orders, addresses and profile.

Hydrogen is Shopify's headless toolkit, and Oxygen is its hosting for Hydrogen storefronts. The Headless channel in the Shopify admin manages API access for every client app. It issues a public token for browser and mobile code and a private one for server code.

Oxygen serves pages from more than 300 points of presence and costs nothing extra on paid plans from Starter through Plus. It isn't offered on Agentic plans. Development stores can use it too, so a team can build and test before the real store goes live.

BigCommerce and Salesforce Commerce Cloud sell the same pattern under their own names. If you're still picking a platform, start with Shopify vs WooCommerce for a small store.

What changed in Shopify Hydrogen in October 2026

Shopify Hydrogen used to be a framework built on React Router, so using its cart meant building the whole storefront on it. On October 14, 2026, Shopify released Hydrogen 2026-10, which works with any JavaScript framework. It handles the commerce parts: cart, variants, prices in the buyer's currency, Shop Pay and customer login. Your framework keeps routing, data loading and rendering.

Two starters ship with it: a React Router template and Vercel Shop, a Next.js storefront that Vercel maintains. A company that already runs a Next.js marketing site can add product pages and a cart to it instead of rebuilding inside Shopify's framework. A store still on PHP can get there through a PHP to Next.js migration first.

Existing Hydrogen storefronts keep working with no action needed. Hydrogen also runs on Vercel, Cloudflare or your own Node server. Shopify adds that Hydrogen storefronts work with shopping agents in WebMCP-enabled browsers, the same shift covered in how online stores sell inside AI chats.

What does headless commerce cost to build and run?

Headless commerce costs more to build and more to run than a theme store, and Shopify says so in its own docs. Before committing, it tells developers to confirm that the merchant "accepts the added cost and complexity" and has developers to maintain the storefront after launch. In our view, that second condition decides more projects than the first.

The build is the visible bill. BigCommerce puts a mid-market headless build at $50,000 to $150,000, with enterprise builds going past $250,000. Those ranges come from one vendor, so read them as scale: you're paying for a custom web application.

Upkeep is the bill people forget. Shopify releases a new API version every three months and supports each stable version for at least 12 months. Once yours drops out of support, Shopify answers with the oldest version it still supports, and code nobody tested against it can break. Plan for one upgrade a year, a full cart and checkout test each time, and someone paid to do both.

Smaller costs pile up around those two. Marketers lose the theme editor, so you pay for a CMS and the hours to load content into it. Hosting and error monitoring cost extra unless Oxygen covers them.

Apps need work too. Reviews, ratings and similar widgets plug into Online Store 2.0 themes through theme app extensions. With no theme to plug into, a developer connects each app through its own API, if it has one. After launch, every front-end change, from a new banner to a broken filter, is developer time.

Will a headless rebuild pay for itself?

Run the numbers on a store doing $40,000 a month. Say a $90,000 rebuild lifts revenue by a tenth, which would be a strong result. At a 40 percent gross margin, that's $1,600 a month of extra profit. The build alone takes close to five years to pay back, before a single hour of retainer.

The math changes when the rebuild opens a new channel, like a mobile app, instead of polishing the one you have. A brand with a funded, dated plan to launch an app or a second brand within 18 months can save itself a second rebuild by building the website headless now. If that plan is a "someday," wait.

Pros and cons of going headless

Design freedom is the first gain: any layout or page type your front-end team can build is on the table. A native app built on the Storefront API and Shopify's Checkout Kit can share the website's catalog and order history. The front-end team also ships on its own schedule while checkout and payments stay on a hosted platform.

The drawbacks are the costs above, paid every year for as long as the storefront exists, plus the app and content work a theme used to absorb. Front-end bugs are now yours to find, and so is slow page speed.

Is a headless store faster than a theme?

Not by default, though speed does pay. Google commissioned Deloitte and the consultancy 55 to track 37 European and American brand sites at the end of 2019. Over 30 days, they logged more than 30 million sessions. In the Milliseconds Make Millions study, a 0.1 second gain in mobile site speed came with an 8.4 percent rise in retail conversions.

But a custom front end is only as fast as the team that builds it. A heavy JavaScript bundle can load slower than a lean theme. So check your Largest Contentful Paint first. Google's target is 2.5 seconds or less at the 75th percentile of page loads, on mobile and on desktop.

If oversized images or too many apps keep your theme above that line, fix those before paying for a rebuild. The steps are in how to improve Core Web Vitals.

Which stores gain from headless commerce

Shopify's own test is a sound one. Go headless when the business systems, processes or customer experience you need can't be achieved with its sales channels, themes and apps. In practice, that points to stores like these:

• A brand selling through a website and a native app from one catalog and one order list.
• Content-led brands, such as a fashion label with editorial lookbooks or a food brand built on recipes, where the CMS carries the business and the shop sits inside it.
• Companies with a custom web app or Next.js site that want to add a shop to it.
• Groups running several brands or regional storefronts off one back end, each with its own design.
• Anything a theme can't present well, like a configurator with live pricing across thousands of combinations.

Compare two stores. The first sells 300 skincare products in two countries, and its theme loads in under two seconds. Its growth plan is more ads and more email, so a rebuild would add a monthly developer bill and change nothing a customer notices.

The second sells made-to-order furniture in 40,000 fabric, size and finish combinations. It runs a mobile app and has a developer in-house. Its theme can't build the product page it needs, so a headless build pays its way there.

Lighter options before a full rebuild

Stay on a theme if you sell a standard catalog in a handful of markets, your marketers edit pages every week, and nobody on staff or on retainer can own a JavaScript app. The same applies when the budget covers the build but not the year after it. For those stores, choosing a better store template is the cheaper fix.

Headless isn't all or nothing either. Shopify's build options include smaller ways to use the same APIs:

• Add products and buy buttons to a site you already have, with Storefront Web Components or Buy Button JS.
• Sell Shopify products on a WordPress site through Shopify's WordPress plugin.
• The new Hydrogen library can go into one part of an existing app, such as a product finder, while the rest stays as it is.
• Keep the theme for the main store and build one headless piece beside it, such as a mobile app reading the same catalog.

Each one shows whether custom front-end work earns its keep before the whole store depends on it.

What to settle before you commit

Work through these inside your team, and ask any agency quoting the work to answer them too:

1. Write down what your theme can't do today. If the list fits on two lines, a theme developer can probably solve it.
2. Name the person who maintains the front end after launch, and the hours a month you've budgeted for them.
3. Assign the yearly API upgrade and the cart and checkout test that goes with it.
4. List the apps the store depends on and check that each one has an API a custom front end can call.
5. Have your marketers build one real page in the CMS they would use.
6. Measure page speed against the 2.5 second target before blaming the theme.

A good partner raises these points before quoting a headless commerce build. One who quotes without asking has priced the build and not the years after it.

If you're weighing a headless rebuild against a better theme, send that written list to our ecommerce website design and development team to get both options priced, with a reply within one business day.