Skip to main content

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 scope is a segmentation layer inside a Frontic project. Every project starts with a single scope called public; most projects never add another. Add a second scope when you need the same data to behave differently for a distinct audience — B2B alongside B2C, a wholesale storefront beside retail, a sub-brand that shares a catalog but shows different prices and copy. Scopes are the coarsest layer of Request Context. Every request resolves to exactly one scope, and storage fields marked scoped can return a different value per scope — a product price that’s 49.99 in public and 39.99 in b2b, or a description that’s consumer-friendly in one scope and technical in another.

​
When to add a scope

Don’t reach for a scope the first time something varies — most variation is better served by regions (market / currency), locales (language), or a scoped field inside the default scope. A new scope is warranted when the split is about who the customer is, not where or what language they speak:

B2B alongside B2C

Same products, different prices, different descriptions, possibly different availability. A separate scope keeps the two worlds clean without a parallel project.

Multi-brand portfolio

Sub-brands that share a product catalog but diverge on branding, naming, and merchandising. Each brand gets its own scope inside one project.

Wholesale vs retail

Wholesale customers see tier pricing and bulk MOQs; retail sees the consumer price. One scope per tier, same underlying data.

Staff-only variant

An internal-only scope for testing new copy or layouts ahead of a public rollout. Request context routing keeps it invisible to real traffic.
If the split is “two completely different experiences with different products and different flows”, that’s a case for two projects — not two scopes. Keep scopes inside one project; use multiple projects when the codebase itself differs.

​
How scopes relate to the rest

A scope is the top of the Request Context hierarchy:
  1. A request arrives with a scope (resolved from a domain or a contextKey).
  2. Inside that scope, one of the scope’s regions is selected — the region carries a currency and a set of locales.
  3. Inside that region, a locale is chosen — determines which translation is returned.
Every scope has its own regions. A region in public is not the same region as one in b2b, even if both are named “Germany” — they’re distinct configuration objects with their own currencies and supported locales.

​
Configuring scopes

Open Settings → Scopes from a project. The scopes list shows every scope with its region count. Click a scope to open its detail view, where you add or edit the regions that live inside it. Scope-level settings themselves are thin — a scope’s identity is mainly its key (used in API responses and field mappings) and the regions attached to it.

​
The default scope

Exactly one scope on a project is flagged as the default — used when a request arrives without enough context to pick a scope explicitly (no domain match, no contextKey carrying a scope). On a fresh project that’s the public scope.

​
Scoped fields

A field on a Data Storage or Block can be marked Scoped. A scoped field stores one value per scope rather than one shared value. When the API responds to a request in scope b2b, the b2b value for that field is returned; when it responds to public, the public value is returned. No per-scope forking in your frontend — the API surface stays the same, only the payload changes. Reach for a scoped field when only part of a record differs per audience — a price, a description, a hero image. If every field of a record would differ, that’s a sign the segmentation belongs elsewhere (a separate record, a separate block, or a separate scope altogether).

Regions

Geographic markets that live inside a scope, each with its own currency and locales.

Multi-channel & region

The full commerce-native picture — scopes, regions, locales, domains working together.

Request Context

How a request resolves to one scope/region/locale combination.

Domains

Where scope/region/locale is bound to an incoming URL.