Product Models

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.

Frontic treats products as a first-class concept, not as generic CRUD records that happen to have a “price” field. When you create a Data Storage with the Products schema type, the stack gives you a parent/child product + variant model out of the box — with built-in composites for pricing, options, media, and SEO that every commerce experience needs. This page covers how that model is shaped, how variants relate to products, and how to work with it across Data Storages, Detail Blocks, and Search Listings.

​

Products vs. Content

When you create a Data Storage, you pick a schema type: Pick Products whenever you’re modeling something a customer can buy. Pick Content for anything else.

​

Product and variant

In Frontic’s model, the variant is the buyable thing — every SKU, every cart line, every price sits at the variant level. The product is a virtual grouping around one or more variants, carrying the attributes they share (name, description, brand). Every product has at least one variant; a product with a single variant (a book, a non-configurable item) is still modeled this way. Every Products storage automatically includes three variant-level fields you can’t remove:

• options — the list of options that define this variant (e.g. color: red, size: M)
• price — the variant’s price, typed as the built-in Price composite
• parentKey — links this variant to its parent product

Plus the key and active fields every storage has.

​

Sharing fields across variants

When you add custom fields to a Products storage, you decide whether each field lives at the variant level (different per variant) or is shared across variants (same for every variant of the product). A good rule of thumb: The Shared Across Variants flag is set per field when you configure the storage. Set it once, and the stack takes care of rolling the right values up to the product or down to the variant automatically.

​

Built-in composites

Frontic ships with composite field types designed for commerce. You use these the same way you use primitives — add them to your storage schema, map source data into them via the Value Composer, and they become first-class parts of your API. These aren’t bolted on — they’re part of the stack. Your blocks and listings can reference any of them directly, and the API Builder knows how to shape them into useful responses.

​

Product-level vs. variant-level blocks

When you create a Detail Block connected to a commerce storage, you pick which level the block operates on. The key thing to understand: shared fields are stable (one value per product), variant fields rotate (one value per variant). A variant block can read the product name, but a product block can’t pick one variant’s price — it needs a strategy to derive it. Most experiences use both: a product-level block for grids and search, a variant-level block for cart and detail views. Both connect to the same storage.

​

Request context on products

Every product response is shaped by Request Context before it hits your frontend. For a product storage specifically, that means:

• Prices are returned in the caller’s currency, based on the resolved region
• Translatable fields (name, description, marketing copy) are returned in the resolved locale
• Scoped fields (e.g. B2B-only descriptions, wholesale-only specs) are returned only if the caller’s scope matches

You don’t write any of this logic. You mark fields Translatable / Scoped / Shared in the storage schema, and the stack does the rest.

​

Mapping from source systems

When you connect a source system via a Connector, its product data shape almost certainly doesn’t match Frontic’s clean parent/variant model. Shopify thinks about products one way, commercetools another, an ERP a third way, and a PIM a fourth. A Data Sync is where those source shapes get mapped into the canonical Frontic structure — splitting flat records into parent + variants, combining variant-level fields, normalizing prices into the Price composite, and so on. The per-field reshaping lives in the Value Composer, where Computed fields chain operations to produce the exact structure each composite type expects. Buddy is good at this step specifically. Point Buddy at a source and describe the target shape, and it’ll propose a Data Sync configuration for you to review and approve.

​

Related