The architecture question every headless CMS ecommerce project must answer correctly on day one: where does product data live? The answer is always the commerce platform — the CMS stores references (product handles or IDs), never copies. Duplicate product data into the CMS and you have created a synchronisation problem that ends with customers seeing yesterday’s prices on this morning’s campaign page. This guide covers the reference pattern, composition in the frontend, editorial workflows, and the proven stack combinations. It builds on our headless commerce architecture and headless commerce SEO guides.

Headless CMS ecommerce — CMS content layer, commerce catalogue layer, the reference pattern and frontend composition by CodeAtoZ

In the reference pattern, a CMS document for a campaign page contains content blocks — hero, editorial copy, image galleries — and product references holding only the commerce platform’s product handle. At render time, the frontend resolves each reference against the commerce API for live title, price, image and availability. The campaign page marketing built in March still shows correct prices in June because it never stored any. Most headless CMSs make this first-class: Sanity has typed reference fields and a Shopify Connect app, Storyblok and Contentful ship commerce field plugins that let editors pick products visually from the connected store while persisting only IDs. The Sanity documentation shows the canonical schema approach for headless CMS ecommerce references.

The frontend in headless CMS ecommerce composes both sources per page: fetch the CMS document (content blocks plus product references), resolve the references against the commerce API — batched into one query, never N+1 — and render. A reusable ProductCard component that accepts a handle and fetches live data is the workhorse: editors drop product references anywhere, the component guarantees freshness. Caching follows the data’s nature — CMS content caches long with webhook-driven revalidation on publish, commerce data caches short (or per-request for inventory-sensitive fields). In Next.js terms: revalidateTag('cms') on the publish webhook, 60-second ISR on resolved product data.

// app/campaign/[slug]/page.tsx
export default async function CampaignPage({params}) {
  // 1. Content from the CMS — cached until publish webhook revalidates
  const page = await sanityFetch(CAMPAIGN_QUERY, {slug: params.slug},
    {next: {tags: ['cms']}});

  // 2. Resolve all product references in ONE commerce query
  const handles = page.blocks
    .filter(b => b._type === 'productRef')
    .map(b => b.handle);
  const products = await getProductsByHandles(handles, // Storefront API
    {next: {revalidate: 60}});

  // 3. Compose: content blocks + live commerce data
  return ;
}

The payoff of headless CMS ecommerce is the editorial workflow: preview mode renders draft content against live products so marketing sees exactly what will ship; scheduled publishing launches campaign pages at midnight without a developer awake; and structured content models keep brand pages consistent. The production-proven stacks: Sanity + Shopify + Next.js (the most common pairing), Strapi + Medusa + Astro for full open source, Contentful + commercetools for enterprise, and headless WordPress + WooCommerce where years of existing content make WordPress-as-CMS the pragmatic choice. Choose the CMS on editorial experience and the commerce platform on commerce needs — the reference pattern decouples them, which is precisely the point. The Storyblok documentation and Strapi documentation cover their commerce field integrations. Our headless commerce team builds headless CMS ecommerce stacks end to end.