Headless commerce: the three tiers, the real options, and which one you probably actually want

What "headless commerce" actually means

Headless commerce means decoupling the frontend (the thing your customer sees) from the commerce backend (cart, checkout, inventory, orders). Instead of picking a platform that bundles both (like Shopify's themed storefronts), you build or buy the frontend separately and wire it to a commerce API.

The word "headless" gets used loosely. Three distinct tiers:

• Full headless: you build the frontend from scratch (React, Next.js, Astro, Nuxt) and call a commerce API for every piece of data. Product listings, cart state, checkout. You own all the UX.
• Widget-embedded headless: your frontend exists already (a marketing site, a Webflow build, a blog). You drop in a commerce widget that renders inside it. Not "full headless" but still decoupled: your site isn't a commerce-platform template.
• Traditional (not headless): you pick Shopify or BigCommerce or WooCommerce, use their theme system, your site IS the commerce platform.

Most of the "headless" hype is about tier 1. Most stores don't actually need it.

When full headless is worth it

Full headless pays for itself in four specific situations. Outside these, it's engineering time you won't recover.

1. You need a custom UX that platform themes can't reach. Interactive configurators, 3D product viewers, content-heavy storytelling layouts. Rebuilding the frontend was going to happen anyway; headless just means you can also control the commerce data flow.
2. Multi-channel distribution from one catalogue. Website + mobile app + in-store kiosk + voice/chat interface. A shared commerce API powering all of them is genuinely hard to do traditionally.
3. Scale where traditional platforms bottleneck. Shopify Plus handles most of this now, but if you're at Nike/IKEA volume, a commerce API behind your own frontend gives you performance controls you don't get from a themed store.
4. Engineering team with real frontend capacity. If you have dedicated frontend engineers, headless becomes genuinely cheaper over time because you stop paying theme-developer tax.

If you don't fall into one of the four, full headless is almost always a worse trade than picking a hosted platform.

The full-headless option set

For teams that do need full headless, the realistic shortlist in 2026:

• commercetools: enterprise-grade, German-engineered, pricey. The reference implementation of composable commerce.
• Saleor: open-source, self-hosted or managed, strong GraphQL API. Dev-friendly.
• Medusa: open-source, JavaScript-native, growing ecosystem. Closer to "Shopify as an API" in shape.
• BigCommerce Headless: use BigCommerce as the backend, bring your own frontend. Cleanest "migrate without rebuilding the backend" option.
• Shopify Storefront API: use Shopify's commerce behind a custom frontend. Hosting + dev complexity is on you; inventory / orders / payments stay in Shopify.
• Shoprocket via the @shoprocket/core SDK: products, cart, and sessions fully programmatic (shoprocket-js). Skip the widget, render your own UI, talk to our API directly. See the "Where Shoprocket sits" section below for the caveats.

Rough ranking by dev ergonomics: Medusa > Saleor > Shopify Storefront API > BigCommerce > commercetools. Rough ranking by enterprise reliability: commercetools > Shopify > BigCommerce > Saleor > Medusa. Pick based on what you're optimising for.

The widget-embedded option (the category most people actually want)

Most businesses describing themselves as wanting "headless" really want this: a marketing or content site they already have, plus commerce that plugs in without forcing a rebuild.

Shoprocket, Snipcart, and Ecwid all sit here. You keep your site (Webflow, WordPress, static HTML, Astro, Framer), you paste in a script tag, the commerce renders inside. It's decoupled but not re-implemented.

<!-- EXAMPLE ONLY. Grab your real snippet from Sales channels → Embeds in your dashboard -->
<script src="https://cdn.shoprocket.io/loader.js" data-pk="pk_yourkey"></script>
<div data-shoprocket="catalog" data-embed-id="emb_xxx"></div>

The API is also available if you want to go further (custom product cards built with your own markup, hitting our API for data). Full programmatic control sits in the JS SDK (shoprocket-js) for events, cart manipulation, and custom UIs.

When this tier beats full headless:

• You already have a site you like (don't want to rebuild the frontend)
• You don't have dedicated frontend engineers
• Your UX requirements fit what the widget renders
• You want commerce shipping in weeks, not quarters

When to graduate to full headless:

• The widget can't reach your required UX
• You need to render products into contexts the widget doesn't cover (native mobile app, kiosks, TV)
• You have the engineering team to support it

How to tell which tier you need

Ask yourself two questions:

1. Would my UX requirements fit inside a rectangular section of my existing website? If yes, widget-embedded is fine. If no, you're in full-headless territory.
2. Do I have a dedicated frontend engineer for the next 18 months? If no, skip full headless regardless of what you think you need.

The second question is the killer. Full headless without a frontend engineer is a pile of technical debt waiting to happen. The commerce platform's vendors will help, but they can't replace having someone who owns your custom frontend.

What about "composable commerce"

Same idea, rebranded for the enterprise buying cycle. "Composable" = pick your best-of-breed for each function (CMS, search, PIM, cart, checkout, tax) and wire them together via APIs. It works when you have the team to wire them. It becomes a maintenance burden when you don't.

For stores under ~$10M/year in revenue, composable is almost always a mistake. The integration surface is massive and every vendor swap breaks something.

Where Shoprocket sits

We cover tiers 1 and 2, and we're honest about which one you should pick.

Tier 2 (widget-embedded), the default for 95% of our customers. Paste one script tag, the widget renders inside your existing site. Catalogue, cart, checkout, search, variants, payments, all handled. Flat subscription from $29/mo, 0% transaction fees. This is the fast path and the right one for most stores.

Tier 1 (full headless), technically supported, rarely recommended. The @shoprocket/core SDK (shoprocket-js) exposes products, cart state, and sessions programmatically. You can render every pixel yourself and talk to our API directly. Same flat subscription backs it.

Why we don't push tier 1 even though it works: covering every edge case in a custom frontend (loading states, empty carts, variant selection UI, checkout flows, error handling, accessibility, mobile viewports, i18n across 21 locales) is a lot of engineering. The widget has all of this baked in, tested across thousands of stores. You're re-implementing a solved problem unless you have a specific UX reason not to.

If you have that specific UX reason and dedicated engineering capacity, the core SDK is there. Otherwise: paste the widget and move on.

Tip: If a vendor calls themselves "headless" without being able to answer "which frontend framework do you recommend?", they're probably widget-embedded. That's fine; just know what you're buying.

TL;DR

• Full headless: commercetools, Saleor, Medusa, Shopify Storefront API, BigCommerce Headless. Only worth it with specific UX needs, multi-channel, scale, or dedicated dev team.
• Widget-embedded: Shoprocket, Snipcart, Ecwid. The right answer for most stores that "want headless". Shoprocket also supports full headless via the core SDK for the rare case you need it.
• Traditional: Shopify + theme, BigCommerce + theme. Still the fastest path if you don't have a site yet.

Most businesses asking for headless actually want the widget-embedded tier. Start a free trial of Shoprocket if that sounds like you. 14 days, no card. Pricing from $29.