CMS for Headless stores

The CMS is the VTEX content management system for defining, storing, and delivering storefront content. In a headless store, it provides the content infrastructure and editorial experience while your team controls the frontend technology, routing, and rendering.

This separation allows developers to model content independently of the storefront implementation and allows editors to create and publish content in the VTEX Admin without changing application code.

Developers define Content Types and components as JSON Schema files in the storefront repository. The Content plugin combines these files into a schema bundle and uploads it to the Schema Registry.

After the schema is available, editors create and publish entries in the CMS Admin. The headless storefront then retrieves the published content from the Data Plane API and maps each component in the response to a corresponding UI component.

Define the content structures required by your storefront using:

• Content Types: Page-level or global structures from which editors create entries, such as home, landingPage, blogPost, globalHeader, and globalFooter.
• Components: Reusable content blocks, such as promotional banners, navigation menus, and rich text sections.
• Fields: Typed and validated values, including strings, numbers, booleans, objects, arrays, references, and media.
• Composition: Reuse definitions with $ref and shared properties with $extends.
• Singletons: Model content that has only one entry, such as a home page, header, or footer.

The headless base schema provides the core platform definitions, while your team defines the Content Types and components required by the storefront. For modeling guidance and recommended patterns, see Content modeling and architecture for headless stores.

Editors manage content through the VTEX Admin with:

• Branches for creating and reviewing changes in isolation.
• Version history for comparing and restoring content.
• Scheduled publishing.
• Multi-user editing awareness.
• Media management for images and video references.
• Locale-specific content.

After publication, the storefront can retrieve content by Content Type, slug, or other entry identifiers. It can also list entries for use cases such as blogs, campaign directories, and static generation.

The storefront can consume content through:

• Data Plane REST API: Retrieve individual entries, list entries, request localized content, and paginate through results.
• GraphQL API: Query content through generic or schema-generated fields. See Using GraphQL API for querying CMS content.

Commerce data such as products, prices, and availability continues to come from the corresponding VTEX Commerce APIs. CMS entries should define the editorial content and presentation configuration that the storefront combines with this commerce data.

The CMS and the storefront have separate responsibilities:

Because the CMS doesn't impose a frontend framework or component library, schema changes and storefront code must stay aligned. When a developer introduces a new component, the storefront must include a renderer for its componentKey before editors publish content that uses it.