Data Types

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 are project-wide type definitions you reference when declaring fields on a Data Storage (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 project storage fields onto the API surface, so the composite shape flows through automatically. Frontic has two kinds of data types:

​

Configuring data types

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

​

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

Practical implication: the storage field types reference 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 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