Shopify on Netlify: Headless Storefront With the Storefront API, Checkout Still on Shopify

A headless Shopify setup on a static host means the storefront, product pages, cart UI, search, is built with a framework like Next.js and deployed on Netlify or a similar static host, pulling product and inventory data from Shopify’s Storefront API. Checkout does not move: Shopify’s own checkout still processes the actual payment and order, either through a hosted checkout redirect or Shopify’s Checkout Kit, because rebuilding PCI-compliant checkout yourself is not the point of going headless. What changes is everything before checkout: the storefront’s design, performance and content.

Tutorials on this topic tend to be framework-specific walkthroughs, a Next.js-and-Shopify guide or a Nuxt-and-Shopify guide, each thorough about the code and thin on the actual decision: what stays on Shopify, what moves to the static host, and whether it is worth the added moving parts for a given store. Here is that decision, then the shape of the setup.

Table of contents

• What headless actually decouples
• The Storefront API in practice
• Where checkout actually happens
• Caching and revalidation
• The cost shape, without naming prices
• Deploying the storefront
• How this fits the rest of the stack
• FAQ

What headless actually decouples

A standard Shopify store uses Shopify’s own theme system to render every page. Going headless replaces the theme with your own frontend, built and deployed separately, which calls Shopify’s Storefront API for product data, collections, inventory and cart state instead of Shopify rendering the HTML.

What does not change: Shopify remains the source of truth for products, inventory, discounts, and orders, and checkout still happens on Shopify’s infrastructure. Headless means a new frontend, not a new backend; the backend Shopify already provides keeps doing its job.

Shopify’s own framework for this, Hydrogen, is one option for the frontend, built specifically around the Storefront API and opinionated about caching. It is not required; a Next.js, Nuxt or SvelteKit project calling the same API works just as well, and the choice mostly comes down to whether the team already has a preferred framework or wants Shopify’s own defaults.

The Storefront API in practice

The Storefront API is a GraphQL endpoint scoped to what a public storefront needs: reading products and collections, creating and updating a cart, and initiating checkout. It does not expose admin operations like changing inventory levels or issuing refunds; that stays on the Admin API, used server-side if at all.

const response = await fetch(
  `https://${SHOP}.myshopify.com/api/2026-01/graphql.json`,
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "X-Shopify-Storefront-Access-Token": STOREFRONT_TOKEN,
    },
    body: JSON.stringify({
      query: `{ products(first: 10) { edges { node { title, handle } } } }`,
    }),
  }
);

The Storefront access token is public-safe by design, scoped to read-and-cart operations only, which is what makes calling it directly from a static frontend reasonable without a backend proxy in between.

Where checkout actually happens

The cart, built from Storefront API mutations, culminates in a checkout URL that Shopify generates. The frontend redirects to it, or embeds it via Shopify’s Checkout Kit for a more integrated feel, but the actual payment form, tax calculation, shipping rate lookup and fraud checks all run on Shopify’s own checkout, not on your static host.

This is the correct division of labor, not a limitation to work around. Payment compliance, tax rules across jurisdictions, and fraud detection are exactly the parts worth leaving to a platform that already handles them at scale, while the storefront experience is where a custom frontend actually adds value.

Caching and revalidation

Product data changes, prices update, items go out of stock, so a fully static build with no revalidation goes stale. Most headless Shopify setups use incremental regeneration or a webhook-triggered rebuild: Shopify fires a webhook on product update, which triggers the static host to rebuild just the affected pages, or the frontend fetches fresh cart and inventory data client-side while product copy and images stay statically served.

The pattern to avoid is fetching live product data on every single page load from the browser; it defeats the performance reason for going static in the first place. Cache aggressively for content that changes rarely, and fetch live only for what genuinely needs to be current, like stock levels at the moment of purchase.

Cart state itself is usually the one thing that should never be cached at the page level, since it is unique per visitor. Most implementations keep the cart entirely client-side, stored in local storage or a cookie referencing a Shopify cart ID, and only touch the Storefront API when the cart actually changes, which keeps the product pages themselves fully static and shareable.

The cost shape, without naming prices

Headless adds moving parts: a frontend framework, a build pipeline, a static host, and the API integration, on top of the Shopify subscription that continues regardless. That is worth it for stores that need a frontend Shopify’s theme system genuinely cannot express, unusual page layouts, non-commerce content mixed into the same site, or performance requirements a heavier theme cannot hit.

For a standard catalog store where the default or a purchased theme already looks and performs fine, headless is added complexity without a matching benefit. The decision is about frontend requirements, not about Shopify being insufficient.

Analytics and tracking pixels need explicit attention in a headless setup, since Shopify’s theme normally injects them automatically on every page. A custom frontend has to fire the same page-view and purchase events itself, usually through Shopify’s own analytics API or a tag manager wired into the checkout redirect, or reporting quietly goes dark on launch day.

Deploying the storefront

The static or server-rendered frontend deploys like any other framework project: build from the repository, environment variables for the Storefront token, and a live route. Headless commerce covers the pattern in more depth if the store side of this decision, rather than the Netlify-specific deploy, is still open.

On RunxBuild, the same static-build path applies for a fully static storefront, or a Next.js service if the frontend needs server-rendered routes for on-demand revalidation rather than a static export.

How this fits the rest of the stack

Whichever framework renders the storefront, the hosting decision is separate from the Shopify subscription and worth pricing on its own: the RunxBuild hosting calculator covers the static site or service side of a headless setup. Static sites on RunxBuild shows the build-from-repository flow for the frontend, and the dashboard is where that repository connects.

Useful related references:

• Headless Ecommerce: The Architecture, and the Bill Attached to It
• Shopify vs WordPress: One Bundles the Work, the Other Bundles the Choice
• Shopify vs Etsy: A Marketplace With Traffic, or a Store You Fully Own
• Static sites on RunxBuild

FAQ

Does headless Shopify still use Shopify checkout?

Yes. Going headless replaces the storefront’s frontend, not its checkout. The cart flow ends at a Shopify-generated checkout URL, either as a redirect or embedded via Checkout Kit, where Shopify handles payment, tax and fraud checks.

Is headless Shopify worth it for a small store?

Usually not, if the default or a purchased theme already meets the store’s needs. Headless adds a frontend build pipeline and hosting on top of the existing Shopify subscription, which pays off mainly when the theme system genuinely cannot express what the frontend needs to do.

What is the Shopify Storefront API?

A GraphQL API scoped to public storefront operations: reading products and collections, and managing a cart through to checkout. It does not expose admin functions like inventory changes or refunds, which keeps its access token safe to use directly from a frontend.

How does a headless Shopify storefront stay up to date with inventory?

Either through webhook-triggered rebuilds when Shopify fires a product update event, or by fetching live cart and inventory data client-side while less time-sensitive content, like product descriptions, stays statically cached.

Can I host a headless Shopify frontend on any static host?

Yes, since the frontend is a normal framework build calling the Storefront API over HTTPS, with no Shopify-specific hosting requirement. A framework needing server-rendered routes for on-demand revalidation needs a host that runs that framework’s server, not a purely static host.