> ## 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.

# Regions

A **region** is a market your project serves inside a specific [scope](https://docs.frontic.com/project-settings/scopes.md). 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](https://docs.frontic.com/project-settings/locales.md)** are supported. Requests resolve to a region via a [domain](https://docs.frontic.com/project-settings/domains.md) 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

> [card] Currency
>
> A single ISO 4217 currency code (`EUR`, `USD`, `JPY`). Products and
> variants can carry prices in any currency; the region decides which
> one comes back in the API response for requests bound to it.

> [card] Supported locales
>
> One or more locales from the project's [locale catalog](https://docs.frontic.com/project-settings/locales.md).
> The region picks which languages are available to its customers;
> one of them is marked the **default**, used when a request doesn't
> specify a locale.

## 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.

**project-settings/regions-per-scope**

Scope detail view listing two regions each with their currency badge and supported locales

![Scope detail view listing two regions each with their currency badge and supported locales](https://mintcdn.com/frontic/8nGuRM1LMzfAjNYy/images/project-settings/regions-per-scope-light.png?fit=max\&auto=format\&n=8nGuRM1LMzfAjNYy\&q=85\&s=21d342e8950d24030c4d0d505eda31f2)

Regions inside a scope - cards showing currency and supported locales

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](https://docs.frontic.com/project-settings/scopes.md#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](https://docs.frontic.com/project-settings/domains.md) row matches.

## A worked setup

A typical cross-market setup for a consumer storefront, all inside the `public` scope:

| Region | Currency | Locales | Default |
| - | - | - | - |
| United States | USD | `en` | `en` |
| Germany | EUR | `de`, `en` | `de` |
| Rest of Europe | EUR | `en`, `de`, `es` | `en` |

The corresponding [domain mapping](https://docs.frontic.com/project-settings/domains.md) binds URLs to these regions:

| Domain | Scope | Region | Locale |
| - | - | - | - |
| `demo-shop.com` | `public` | United States (USD) | `en` |
| `demo-shop.com/de` | `public` | Germany (EUR) | `de` |
| `demo-shop.com/es` | `public` | Rest of Europe (EUR) | `es` |

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](https://docs.frontic.com/project-settings/domains.md) 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](https://docs.frontic.com/project-settings/scopes.md) - that's the only mechanism for returning different content from a field.

## Related

> [card] [Scopes](https://docs.frontic.com/project-settings/scopes.md)
>
> The segmentation layer regions live inside (B2B vs B2C, multi-brand).

> [card] [Locales](https://docs.frontic.com/project-settings/locales.md)
>
> The language catalog regions pick from.

> [card] [Domains](https://docs.frontic.com/project-settings/domains.md)
>
> How incoming URLs bind to a specific region.

> [card] [Multi-channel & region](https://docs.frontic.com/commerce-concepts/multi-channel-region.md)
>
> The commerce-native view of how scopes, regions, locales, and
> domains compose.


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