Content + Commerce: Integrating UCP with Modern CMS Platforms

The Content-Commerce Gap

Commerce platforms handle transactions. CMS platforms handle content. In most modern stacks, they are different systems. Shopify or commercetools manages the product catalog, pricing, and checkout. Sanity or Storyblok manages the descriptions, editorial copy, promotional banners, and landing page content.

For a human browsing a storefront, this separation is invisible. The browser assembles content and commerce data into a unified UI. For an AI agent, the separation is explicit. The agent must query both systems to build a complete picture of a product before making a purchase decision.

Understanding how CMS APIs work, and how they relate to commerce APIs, is foundational for agents operating in composable commerce environments.

Why Content Matters for Purchase Decisions

Product data from a commerce backend is transactional: SKU, price, inventory count, variant options, shipping weight. It answers the question: what is available and how much does it cost?

Content from a CMS answers different questions: what is this product and why does it matter? Long-form descriptions, ingredient lists, size guides, sustainability claims, comparison tables, and promotional terms all live in the CMS. An agent making a purchase recommendation needs both.

An agent that only reads commerce data might find 50 products matching a search query but have no basis to distinguish them beyond price. An agent that also queries CMS content can surface the product that best matches the buyer's stated preferences using detailed attribute data that lives in the content layer.

The content layer is also where context lives. Return policy terms, warranty information, compatibility notes, and care instructions are often managed in a CMS. Agents surface this context to buyers during the recommendation flow.

Structured Content Is Machine-Readable Content

The key feature of headless CMS platforms for agent use is structured content. Unlike traditional CMS platforms that store content as HTML blobs, headless CMS platforms store content as typed, structured documents.

A product document in Sanity might have fields typed as string, number, array of references, and portable text. The GROQ API returns these typed values as JSON. There is no HTML to parse, no DOM to traverse, no unstructured text to extract. The content is already machine-readable.

This is what makes headless CMS APIs valuable for agents. The investment commerce teams have made in structured content modeling pays off when AI agents interact with the data. Well-structured content is easy to query, filter, and reason about.

Sanity: GROQ Queries for Agent Context

Sanity's GROQ query language is one of the most agent-friendly content retrieval mechanisms in the CMS ecosystem. Agents write GROQ expressions that traverse document relationships in a single query:

const products = await client.fetch(
  `*[_type == "product" && inStock == true] {
    name,
    "slug": slug.current,
    price,
    description,
    "categories": categories[]->{ name },
    "imageUrl": mainImage.asset->url
  } | order(price asc) [0...20]`
);

This query returns 20 in-stock products ordered by price, with resolved category references and image URLs, in a single request. No additional calls needed to resolve references. GROQ handles it inline.

Sanity is particularly useful for agents that need to match product attributes against buyer preferences. The structured content model means every product has the same typed fields. Agents can filter reliably without dealing with inconsistent data shapes across products. Sanity's portable text format represents rich text as structured JSON, making it straightforward for agents to extract key points from product descriptions without parsing HTML.

Storyblok: Component Trees as Agent Data

Storyblok organizes content as Stories made of blocks. Each block has a defined component type and a set of typed fields. This structure is consistent and predictable across all content in a Storyblok space.

Agents query Storyblok stories and extract specific block types to surface relevant information:

const story = await fetch(
  'https://api.storyblok.com/v2/cdn/stories/products/' + slug + '?token=' + token
).then(r => r.json());

const featureList = story.story.content.body.find(
  (b: { component: string }) => b.component === 'feature_list'
);
const features = featureList?.items?.map((i: { text: string }) => i.text) ?? [];

For agents, the consistent block structure means content extraction is reliable. A product page will always have a "feature_list" block if the content model requires one. Agents implement extraction logic once per block type and apply it across all product pages without per-product customization.

Storyblok's resolve_relations parameter resolves linked content in a single request. An agent querying a promotional story can get the linked product data, linked category data, and linked author data all in one API call.

Prismic: Typed Slices Without Parsing

Prismic's Slice Machine generates TypeScript types from Slice schemas. The API returns content with "slice_type" identifiers that map to the generated types. Agents can process content with predictable field access:

const document = await client.getByUID('product', slug);

const techSpecs = document.data.slices.find(
  s => s.slice_type === 'technical_specifications'
);
const specs = techSpecs?.items?.map(i => ({
  label: i.spec_name,
  value: i.spec_value,
})) ?? [];

Typed Slice responses are reliable: "spec_name" and "spec_value" are always present if the Slice schema requires them. Agents do not need defensive parsing for missing fields within typed Slice structures. This reliability is important when agents are processing hundreds of product pages in a single session.

Prismic's "fetchLinks" parameter resolves linked documents inline, so agents can retrieve a product page with its linked category, brand, and variant documents in a single request.

Connecting CMS Context to UCP Checkout

The typical agent flow in a content-rich composable stack:

1. Agent receives a buyer request with preferences
2. Agent queries the CMS for products matching the preferences using structured content fields
3. Agent queries the commerce backend for pricing, inventory, and variant availability
4. Agent presents recommendations with rich content context to the buyer
5. Buyer approves a selection
6. Agent initiates checkout through the UCP endpoint

Steps 2 and 3 use separate APIs. The CMS provides context. The commerce backend provides transactional data. UCP standardizes step 6 regardless of which CMS or commerce backend the merchant uses.

This separation of concerns is intentional. CMS platforms are optimized for content retrieval and editorial workflows. Commerce platforms are optimized for transactional operations. UCP standardizes the checkout interface so agents do not need custom checkout code for each merchant.

What This Means for Agent Developers

Agents that only integrate with commerce APIs miss the content layer that makes purchase recommendations meaningful. Agents that also integrate with CMS APIs can surface richer and more accurate recommendations with full context.

The investment in a CMS integration pays off across all merchants using that CMS. An agent that can query Sanity can work with any merchant using Sanity as their content layer. The integration work is done once.

The platforms in this category (Sanity, Storyblok, Prismic, Contentful, Hygraph) are the content layer of the composable stack. Each exposes structured content through a clean API. Each is a worthwhile integration for agents operating in composable commerce environments.

Browse the Composable Commerce category in UCPList for current CMS platform integration status and the full list of headless CMS tools in the ecosystem.