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

# Data Types

**Data Types** are project-wide type definitions you reference when declaring fields on a [Data Storage](/data-integration/data-storages) (or inside another composite). Instead of redefining "price with currency and cents" every time you need it, you define it once in the project and reference it by name. [Blocks](/api-builder/blocks) project storage fields onto the API surface, so the composite shape flows through automatically.

Frontic has two kinds of data types:

<CardGroup cols={2}>
  <Card title="Composites" icon="cube">
    Structured compositions of primitive fields grouped into a named
    shape. Composites give you typed object fields without repeating
    their inner shape on every storage.
  </Card>

  <Card title="Enums" icon="list">
    A fixed list of allowed keys. Enums keep categorical data
    consistent and let the agent reason about the complete set of
    values when building UI.
  </Card>
</CardGroup>

## Configuring data types

Open **Settings → Data Types**. Two sections, one per kind — **Composites** and **Enums** — each with a list and a **New** button.

<Screenshot name="project-settings/data-types-list" caption="Data Types — Composites and Enums defined at the project level" alt="Project Settings Data Types page with a Composites section and an Enums section, each listing the project's definitions" />

### Composites

A composite has:

* **Name** and **Key** — display label and stable identifier.
* **Fields** — each a primitive type (`string`, `integer`, `boolean`, `datetime`, etc.) with its own name, key, and optional constraints. A field can also be another composite, giving you nested structures.

Composites can reference other composites. A `Product` composite might include an `Image` composite for its hero media and a `Price` composite for its list price — no need to flatten the structure into one long field list.

### Enums

An enum has:

* **Name** and **Key** — display label and stable identifier.
* **Values** — each is a single `key` string (e.g. `in-stock`, `preorder`).

API responses return the enum's key, and the frontend picks the label or icon to render for each value. Adding new keys is fine; renaming an existing key is a breaking change — existing records using the old key become orphaned.

## Built-in data types

Frontic ships a set of commerce shapes out of the box — `Price`, `Media`, `Availability`, `Option`, `SEO`, and more — always available in every project. See the [storage field types reference](/reference/storage-field-types#composites) for the full catalogue.

Use the built-ins when they fit. They're a shared vocabulary the rest of the stack and the agents recognise across projects — for example, the `Option` composite auto-generates dynamic filter facets when used in a listing.

## Extending the built-ins

Built-in composites and enums are **extensible without being breakable**. Open one in **Settings → Data Types** and you'll see:

* The built-in fields/keys are read-only — name, description, icon, and the system fields/keys can't be edited or removed. They're a guaranteed contract every project starts with.
* You can **add your own fields to a composite** (e.g. a `vendorSku` field on the built-in `Media` composite) or **add your own keys to an enum** (e.g. a `clearance` key on the built-in `Availability` enum). Custom additions appear alongside the built-ins on every record that uses the type.
* Fields/keys you've added are yours to delete or rename.

<Screenshot name="project-settings/data-types-extending" caption="Extending a built-in composite — system fields locked, custom fields added below" alt="Composite editor for the Media composite showing its system fields with disabled controls and a custom vendorSku field added at the bottom with a delete button" />

Practical implication: the [storage field types reference](/reference/storage-field-types) documents the **minimum shape** of each built-in. Real responses in your project may include extra fields or keys you've added on top — and the [Client SDK](/reference/client-sdk) generated by `frontic generate` reflects your project's *actual* shape, so the extras come back typed in your frontend without you spelling them out anywhere.

## Custom data types

You can also create your own composites and enums from scratch — `BrandTheme`, `WarrantyTier`, `LegalDocument`, anything your project models that doesn't fit a built-in. Custom data types live alongside the built-ins in the same Data Types page; they're treated identically by every field input across the project.

Reach for a custom type when:

* The same set of fields appears on multiple storages (a `BrandTheme` shared between a Brands storage and a Themes storage).
* A field needs strong domain semantics the agent should respect (a `WarrantyTier` enum so AI-generated copy doesn't invent tier names).
* You want one place to evolve a shape — add a field to the composite, every storage using it picks the change up.

## Related

<CardGroup cols={2}>
  <Card title="Storage field types reference" icon="book" href="/reference/storage-field-types">
    Catalogue of primitive types and the built-in composites and enums.
  </Card>

  <Card title="Data Storages" icon="database" href="/data-integration/data-storages">
    Where composites and enums get used in schema fields.
  </Card>

  <Card title="Blocks" icon="cube" href="/api-builder/blocks">
    How composites and enums compose the API surface exposed to your frontend.
  </Card>

  <Card title="Client SDK" icon="code" href="/reference/client-sdk">
    Generated typed access to your project's actual schema, including any extensions you've added.
  </Card>
</CardGroup>