Regions

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 region is a market your project serves inside a specific scope. Regions are typically geographic (Germany, United States, APAC) but they’re whatever subdivision carries its own currency and supported languages. Every region belongs to exactly one scope — the public scope has its own regions; a b2b scope has its own separate regions, even if the names overlap. A region does two things: it fixes the currency used for pricing, and it declares which locales are supported. Requests resolve to a region via a domain mapping or a contextKey, and the rest of the response adapts from there — prices in the region’s currency, translations in the resolved locale.

​

What a region holds

​

Configuring regions

Open Settings → Scopes, pick the scope you want, and manage its regions inside the scope’s detail view. There’s no standalone “Regions” page in the admin UI — regions always live inside a scope. When you add a region, Frontic prompts for:

• Name — human-readable label, e.g. “Germany” or “North America”.
• Key — short, stable identifier (de, na). Surfaces in API responses, in request parameters, and in any frontend code or downstream system that targets the region by name. Frontic’s own configuration references regions by record ID, so a rename won’t break the project itself — but anything outside Frontic that hardcoded the old key (Client SDK calls, analytics dimensions, partner integrations) needs to update at the same time.
• Currency — the ISO currency code for pricing.
• Supported locales — one or more locales from the project catalog.
• Default locale — which supported locale applies when none is specified.

​

The default region per scope

Each scope has one default region — the one that’s used when a request resolves to that scope but doesn’t carry enough information to pick a region. The first region you add to a scope is automatically marked default; you can flip the flag from any region’s edit screen afterwards. Pair this with the default scope flag and you’ve got the full fallback chain: no scope → project default scope; no region → that scope’s default region; no locale → the region’s default locale. Together they’re what lets a request always succeed even when no domain row matches.

​

A worked setup

A typical cross-market setup for a consumer storefront, all inside the public scope: The corresponding domain mapping binds URLs to these regions: If a customer hits a URL that doesn’t match any domain row, Frontic walks the default cascade (default scope → default region → default locale) and serves the request rather than rejecting it — see domains for the full resolution flow.

​

Regions and the product catalog

Currency and locale decisions ripple through the catalog:

• Pricing — a product variant stores prices per currency. When a request arrives in a region with currency EUR, the EUR price comes back.
• Translations — a field marked Translatable stores one value per locale. The region’s active locale picks which translation is returned.

Beyond currency and locale, regions don’t cause field values to differ. For non-translation content that should vary per audience (B2B prices, brand-specific copy, scope-specific availability), use scopes — that’s the only mechanism for returning different content from a field.

​

Related