> ## 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](https://docs.frontic.com/data-integration/data-storages.md) (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](https://docs.frontic.com/api-builder/blocks.md) project storage fields onto the API surface, so the composite shape flows through automatically.

Frontic has two kinds of data types:

> [card] Composites
>
> 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] Enums
>
> 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.

## Configuring data types

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

**project-settings/data-types-list**

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](https://docs.frontic.com/reference/storage-field-types.md#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.

**project-settings/data-types-extending**

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](https://docs.frontic.com/reference/storage-field-types.md) 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](https://docs.frontic.com/reference/client-sdk.md) 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

> [card] [Storage field types reference](https://docs.frontic.com/reference/storage-field-types.md)
>
> Catalogue of primitive types and the built-in composites and enums.

> [card] [Data Storages](https://docs.frontic.com/data-integration/data-storages.md)
>
> Where composites and enums get used in schema fields.

> [card] [Blocks](https://docs.frontic.com/api-builder/blocks.md)
>
> How composites and enums compose the API surface exposed to your frontend.

> [card] [Client SDK](https://docs.frontic.com/reference/client-sdk.md)
>
> Generated typed access to your project's actual schema, including any extensions you've added.


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