What’s included
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.
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.
Blocks
Block definitions: parameters, fields, storage connections, nested blocks,
variant list configurations, variant field rollups.
Listings
Listing definitions: filters, sorts, search configuration, pagination,
facets, and the per-item block shape.
Pages & Routing
Page definitions, slug field assignments, withdrawal actions, conflict
resolution strategies, menu structures.
Project settings
Scopes, regions, locales, domain mappings, data types. The axes
that shape Request Context
for every API response.
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 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 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 - Experience Designer experiences and their saved versions have their own publishing 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
Release Control
The workspace, the API versions and how a change moves through
them.
Release Flow
Preview a version, publish it, version keys and how the Fetch API
picks a version.