Headless Commerce
Definition
Headless commerce means separating the interface a shopper sees from the commerce functions that handle products, inventory, orders and payment. The "head" being removed is the interface; commerce is consumed through an API.
On Shopify, products, inventory, orders and checkout all stay with Shopify. What changes is only the storefront implementation: instead of a theme, you deploy your own web application and render data fetched from the Storefront API. For a signed-in account area, the Customer Account API covers it.
What actually changes
| Aspect | Theme | Headless |
|---|---|---|
| Interface | A Shopify theme, in Liquid | Your own web application |
| Data | Resolved by the theme inside Shopify | Fetched from the Storefront API and others |
| Hosting | Shopify | Oxygen, Vercel, Cloudflare and so on |
| Checkout | Shopify | Shopify, unchanged |
| Apps | Added through theme app extensions | Built yourself, or integrated through APIs |
Checkout always staying on Shopify's side matters: payment handling and the PCI scope do not move onto you by going headless.
Ways to build it
Shopify's own Hydrogen and Oxygen, or a general framework such as Next.js, Nuxt or Astro. On content-heavy sites it is common to hold everything that is not product data in a headless CMS and combine the two.
Background
Why teams choose it
The reasons fall into roughly four groups. Building a brand experience down to the detail. Designing around content, when much of the site is not product data. Serving the same commerce data to channels beyond the web. Holding control of performance and implementation in-house.
Each of them is really "something the theme framework makes difficult". Which also means that if the difficulty is not real for your project, neither is the reason to go headless.
What you take on in return
Going headless moves the frontend responsibility Shopify had been carrying onto your team. Builds and deploys, hosting, monitoring, SEO and accessibility, and keeping up with API versions all become ongoing work.
The part most often missed is apps: an app that installs into a theme through a theme app extension does not run on a headless frontend. Where equivalent functionality is needed, it has to be integrated through an API or rebuilt. The trade-off usually summarised as "more operational cost and complexity" is this accumulation of specifics.
Examples in Japan
Headless Shopify stores are running in Japan, and as far as can be observed from the public sites, no two are built the same way (as of September 2026).
| Site | Frontend | Note |
|---|---|---|
| flagship.inc (our own corporate site) | Hydrogen and Oxygen | Content managed in Sanity |
| Paul Smith | Nuxt on Vercel | Built without Shopify's own framework |
| YAMAP STORE | Next.js | Checkout on its own domain |
All three sit on Shopify, and none of them share a frontend stack. Headless names a separation, not a particular set of technologies, and whether to use Hydrogen is one choice inside it.
Deciding against it matters just as much
An Online Store 2.0 theme covers a great deal, section-level editing and app integration included. Bringing headless to requirements a theme already satisfies buys less freedom than it costs in operation.
Flagship's Involvement
Our own corporate site, the one you are reading, is a headless build on Hydrogen and Oxygen. Content including this glossary is managed in Sanity, while product and article data comes from Shopify. We run the architecture we recommend, which means we deal with the migration decision, the deploys and the monitoring on an ongoing basis.
For clients we work through whether headless is warranted or an Online Store 2.0 theme is enough, weighing requirements, scale and the team that will operate it. That includes not recommending headless where a theme would do. What Hydrogen is actually good at, and where it is awkward, we have written up from rebuilding our own site.