> ## 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](/project-settings/scopes). 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](/project-settings/locales)** are supported. Requests resolve to a region via a [domain](/project-settings/domains) 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

<CardGroup cols={2}>
  <Card title="Currency" icon="coins">
    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>

  <Card title="Supported locales" icon="language">
    One or more locales from the project's [locale catalog](/project-settings/locales).
    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.
  </Card>
</CardGroup>

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

<Screenshot name="project-settings/regions-per-scope" caption="Regions inside a scope — cards showing currency and supported locales" alt="Scope detail view listing two regions each with their currency badge 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](/project-settings/scopes#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](/project-settings/domains) 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](/project-settings/domains) 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](/project-settings/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](/project-settings/scopes) — that's the only mechanism for returning different content from a field.

## Related

<CardGroup cols={2}>
  <Card title="Scopes" icon="layer-group" href="/project-settings/scopes">
    The segmentation layer regions live inside (B2B vs B2C, multi-brand).
  </Card>

  <Card title="Locales" icon="language" href="/project-settings/locales">
    The language catalog regions pick from.
  </Card>

  <Card title="Domains" icon="globe" href="/project-settings/domains">
    How incoming URLs bind to a specific region.
  </Card>

  <Card title="Multi-channel & region" icon="sitemap" href="/commerce-concepts/multi-channel-region">
    The commerce-native view of how scopes, regions, locales, and
    domains compose.
  </Card>
</CardGroup>