Core Concepts

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.

A short tour of the mental model behind Frontic. Each concept gets a paragraph with a link to the full coverage; if you want to follow one to its depth, click through. Reading top to bottom gives you the map without forcing you into the detail.

​

Project and Team

Two layers sit above your work in Frontic:

• A Team is the place where members live and billing happens — and the boundary for shared resources: Connectors and their Data Feeds, the plan, and Context Base documents promoted to global scope. Most companies have one team; agencies and fully separate engagements have more.
• A project lives inside a team and contains the stack itself — Data Storages, Blocks, Listings, Pages, Trees, project settings. The recommended default is one project per codebase: the typed Client SDK type-checks against that repo, Release Control lines up with the deploy pipeline, and the GitHub integration assumes the same pairing. Markets, domains, brands, and locales compose inside a project via scopes, regions, and locale mappings — splitting those across parallel projects almost always creates more work than it saves.

When the docs talk about “your project” they mean one stack instance; when they talk about “your team” they mean the umbrella above.

​

The Stack

The stack is a pipeline that turns messy source data into an API that’s both requestable (the exact shape your experience needs) and semantically meaningful (so humans, agents, and AI tooling can reason about it). Every stack instance walks through the same stages.

​

Connectors and Data Feeds

A Connector is the bridge between Frontic and a source system — Shopware, commercetools, a PIM like Akeneo, a CMS like Storyblok or Contentful, the Reviews.io API, n8n, file imports, or a custom REST endpoint. Each connector exposes one or more Data Feeds — the unshaped raw records as the source sends them. A single team can connect any number of sources; every project in the team can pull from any feed.

​

Data Storages

A Data Storage is where data lives in its shaped, semantically meaningful form. You define a schema (product, article, category, whatever your experience needs) and records get mapped from a feed into the storage via a Data Sync. The schema is what gives the data meaning — not “field42 is a string” but “this is a product’s short description in the customer’s language.” A few schema details worth knowing exist as their own concepts:

• Data Types — composites and enums you define once at the project level and reuse on any field. Frontic ships built-ins (Price, Media, Availability, Option, SEO, …) you can extend without breaking.
• Mapped fields — fields that pull their value from another storage at response time. Pull brand.name from the Brands storage onto every product without duplicating it in the sync.

​

Data Sync and Value Composer

A Data Sync wires a Data Feed to a Data Storage. It carries two things: the channel mappings (which integration scopes / regions / locales land in which project ones) and the Value Composer — the per-field configuration that says how every field of the target record gets its value from the incoming feed record. Each composer field is one of four modes: schema (pull a value from the feed), computed (chain operations to derive a value), static (a constant), or keep empty. Computed mode is where legacy schemas get reshaped into clean, well-typed structures the rest of the stack and the agents can reason about.

​

Blocks, Listings, Pages, and Trees

Once data is shaped, the API Builder turns it into the exact API surface your experience needs:

• Blocks — named, versioned API responses keyed by a record. A ProductCard, CategoryHero, StoreLocator. One block returns exactly what one component needs.
• Listings — query-based collections with filtering, sorting, search, pagination, and facets. Product lists, article archives, anything that’s “many of something filtered and sorted.”
• Pages — route-level API responses. A page binds a URL pattern to a Detail Block and resolves the record for that URL.
• Trees — hierarchical block structures for navigation menus, category trees, breadcrumbs, anything where parent/child relationships matter. Returned as a single response your frontend renders without extra round-trips.

Together they form the request surface every shopping experience hits — typed, predictable, no per-component endpoint hand-rolling.

​

Request Context

Every API call resolves against a Request Context — a triple of scope / region / locale — before any data is returned. The four axes are project-level concepts:

• Scope — segmentation (B2B vs B2C, multi-brand). Every project starts with a public scope.
• Region — a market inside a scope, carrying a currency and a set of supported locales.
• Locale — a language; translatable fields resolve per locale.
• Domain — binds a URL value (passed by the app as contextDomain) to a specific scope/region/locale triple. The app can also carry a contextKey for session-level overrides.

What lets one block or listing serve many markets, audiences, and languages from a single definition is that scoped fields, translatable fields, and per-region pricing all resolve transparently against the active context.

​

Releases

Releases are how the stack ships. Every project has three stages running in parallel — develop, preview, and public — each a clone with its own version token and its own copy of the stack configuration. You build in develop, snapshot to preview when you want to share a candidate state for review, then promote preview to public when it’s ready. A release bundles everything that changed (storages, syncs, blocks, listings, pages, project settings) and rolls out together — not API versioning, the whole project config.

​

How to manage the stack

Configuring the stack — adding storages, defining fields, building blocks, wiring syncs, publishing releases — happens in the admin surface. Four ways to do it:

​

Admin app

The Frontic admin app at app.frontic.com is the foundational surface — direct clicks, full control, every option exposed. Use it when you want to see exactly what’s there, when you’re learning the system, or when an agent gets something wrong and you want to fix it by hand.

​

Buddy

Buddy is the AI assistant living inside the admin app, available everywhere except inside a Studio workspace. Buddy knows your business and configures the stack on your behalf — set up integrations, define Data Storages, wire syncs, build blocks/listings/pages, prepare releases. Buddy doesn’t edit code; it works on stack configuration only, with approval gates on every mutation.

​

Studio chat

The chat agent inside a Studio workspace primarily creates the experience (frontend code, components, visuals), but it can adjust stack config when a code change requires one — for example, adding a field to a block to surface a new piece of data the new component needs. That’s a side effect, not the chat’s main job.

​

MCP tools

Editor agents (Claude Code, Cursor, any MCP-capable client) connected to the Frontic MCP can read and write the project’s stack from your editor — create blocks, configure listings, edit data syncs, search storage records, all without leaving your IDE. Same scope as Buddy, different surface.

​

How to build on the stack

Writing the experience itself — the code, the components, the visuals — happens in your repository. Two surfaces for that:

​

Studio

Frontic Studio is the AI workspace for building the experience. A Studio job gives you a chat agent tied to a live preview, file-editing capabilities for the repo, and a Changes panel where you review and commit. Studio is the right place for “describe what you want and watch it ship.” When the agent needs the stack to provide a piece of data, it nudges the stack as part of the job (see “How to manage the stack” above).

​

Your editor

If you’d rather stay in your editor, the full stack is available through:

• Frontic CLI — generate the typed Client SDK, sync the Context Base, wire up the MCP servers in your editor’s config.
• Client SDK and Nuxt module — typed access to your project’s blocks, listings, pages, and trees from frontend code.
• MCP in your IDE — same MCP that powers stack management, available to your editor agent so it can call Frontic tools while it writes code.

The same stack, the same data, a different IDE.

​

The Context Base

The Context Base is the knowledge layer agents read from before they start working — the team’s expectations encoded as documents. Four collection types:

• Skills — domain expertise auto-applied when a matching task comes up (shopware-headless-commerce, seo-optimizer, product-variants-and-scopes).
• Rules — always-on constraints (product-images-through-cdn, cover-i18n-for-new-strings).
• Commands — task procedures invoked by name (/build-landing-page, /verify-accessibility).
• Guides — long reference documents pinned for chat to pull in on demand.

Context Base content shapes both axes above — the Studio chat reads it when managing or building, and editor agents read it after frontic context init syncs the documents into your repo. It’s the same Context Base regardless of where the agent is working. Documents can be project-scoped or promoted to your team for use across every project. Buddy sits slightly outside this — Buddy can read and edit Context Base documents on your behalf, but its own behaviour is governed by a separate setup, not by Context Base rules and skills.

​

How the pieces fit together

Data flows left to right through the stack, gaining meaning at each step: Above that pipeline, four ways to manage the stack (admin app, Buddy, Studio chat, editor MCP) and two ways to build on it (Studio, your editor). Across both, the Context Base shapes how every agent works.

​

Next steps