> ## Documentation Index
> Fetch the complete documentation index at: https://docs.frontic.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What's in an API Version

An API version is more than an API surface. Each one carries the **entire project configuration** from one moment, and you preview and publish it as one unit. This page lists what a version carries, so you know what holds still in a preview version and what you publish, and what all versions share.

## What's included

> [card] Storage schemas
>
> Field definitions, types, translatable/scoped flags, shared-across-variants
> flags, composite configurations. If you add, rename, remove, or change the
> type of a field, the new schema goes into the next version you preview.

> [card] Syncs
>
> Every sync configuration - source feed, target storage, and the Value
> Composer mappings that transform one into the other. A Composer expression
> change is worth a release.

> [card] Blocks
>
> Block definitions: parameters, fields, storage connections, nested blocks,
> variant list configurations, variant field rollups.

> [card] Listings
>
> Listing definitions: filters, sorts, search configuration, pagination,
> facets, and the per-item block shape.

> [card] Pages & Routing
>
> Page definitions, slug field assignments, withdrawal actions, conflict
> resolution strategies, menu structures.

> [card] Project settings
>
> Scopes, regions, locales, domain mappings, data types. The axes
> that shape [Request Context](https://docs.frontic.com/api-builder/overview.md#request-context)
> for every API response.

Plus anything else that affects the shape or content of an API response - if it changes what your frontend sees, it's in the version.

## What's not included

API versions carry **project configuration**. The data pipeline, the tools you build with and team-level state sit outside Release Control:

* **Data feeds** - the raw records pushed in by your connectors (Shopify, Shopware, a PIM, a CMS). Feeds are team-level and always on; they flow into Frontic whichever version is public. A product update in Shopify lands in the feed layer at once.
* **Ingest credentials** - connector authentication lives in project settings and is the same for every version. Publishing a version doesn't rotate credentials.
* **[Context Base](https://docs.frontic.com/context-base/overview.md) content** - Skills, Rules, and Commands are a separate surface from the Stack and are not part of any API version. They apply at once to the next conversation with Buddy or Studio.
* **[Studio](https://docs.frontic.com/studio/frontic-studio.md) jobs** - jobs, their workspaces and their chats are not part of any API version. Previewing or publishing a version leaves them as they are.
* **[Experiences](https://docs.frontic.com/designer/overview.md)** - Experience Designer experiences and their saved versions have their own [publishing](https://docs.frontic.com/designer/publishing.md) and are not part of any API version.
* **Design Library** - brand tokens and components have their own publish step and are not part of any API version.
* **Admin-level state** - teams, members, billing. These live above the project and don't change with a version.

## What about the data?

Project data - storage records, block outputs, listing indices, generated URLs - *is* tied to its version. It isn't part of the snapshot; each version processes your data itself. When you preview a version, Frontic snapshots the workspace end to end (storages, syncs, blocks, listings, pages, project settings) and processes your data with that configuration. The preview version gets its own data set, shaped by its own configuration. That's why each version stays consistent: its schema, sync mappings, records and API responses match each other by construction.

Every version reads the same shared feeds. A product update in the feed layer flows into the workspace, the preview version and the public version in parallel, each processed through its own configuration. Changing configuration in the workspace reprocesses the workspace's records only. Publishing makes the preview version the public version; it has kept up with your data all along, so publishing is instant and doesn't trigger a rebuild. Feeds are shared across versions; everything downstream (storages, records, block indices) is per version.

Work for the public version, such as processing a feed update, never waits behind work in the workspace.

## Related

> [card] [Release Control](https://docs.frontic.com/releases/overview.md)
>
> The workspace, the API versions and how a change moves through
> them.

> [card] [Release Flow](https://docs.frontic.com/releases/release-flow.md)
>
> Preview a version, publish it, version keys and how the Fetch API
> picks a version.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.