Modelling content
Content models
A content model is the blueprint for a kind of content. Define the fields once, and every entry of that type follows the same structure.
Creating a model
- Go to Content Models in the sidebar
- Click New Model The button is in the top-right corner.
-
Enter a name
For example
Product. The URL slug generates automatically and is what you will use in API calls. - Add your fields Pick a type for each one, and mark the fields an entry cannot exist without as required.
- Click Save The model is immediately available when creating content.
Start small. You can add, remove and reorder fields at any time. Model the fields your storefront renders today rather than every field you can imagine wanting.
A worked example: Product
This is a realistic starting point for a retail catalogue. It assumes a separate Category model exists for the relation field to point at.
Product
API slug: product
text
Name required
Display name on the product page
text
SKU required
Matches your commerce platform
text
Slug
Used to build the product URL
richtext
Description
Formatted marketing copy
textarea
Short description
For listing tiles and meta descriptions
number
RRP
Display price, if you hold it here
media_multiple
Gallery
Packshots and lifestyle imagery
media
Size guide
A PDF attachment
relation
Category
Links to a Category entry
boolean
Featured
Surfaces the product on the homepage
Price and stock usually belong in your commerce platform rather than your CMS, because they change far more often than copy does. Hold them here only if this is genuinely your source of truth.
All field types
Ten types, covering the structures most retail content needs.
text
Short text
Names, SKUs, slugs, URLs, button labels
textarea
Long text
Summaries, excerpts, meta descriptions
richtext
Rich text editor
Formatted product copy, articles, guides
number
Number
Prices, weights, sort order, ratings
boolean
True / false
Featured flags, visibility toggles, badges
date
Date
Launch dates, campaign windows, deadlines
media
Single media
Hero image, thumbnail, PDF attachment
media_multiple
Multiple media
Product galleries, lookbooks, downloads
relation
Relation
Links to one other entry, such as a category
relation_multiple
Multiple relations
Tags, collections, related products
How models reach the API
The model slug becomes the filter in your API calls, and the field names become the
keys inside each entry's data object.
GET /api/content/model/product
{
"id": 214,
"model": "product",
"model_name": "Product",
"data": {
"name": "Alpine Down Parka",
"sku": "APK-2291-BLK",
"featured": true,
"category": { "id": 12, "name": "Winter outerwear" }
}
}
Renaming a field changes your API response. Field names become JSON keys, so renaming one after go-live breaks whatever reads it. Settle on naming before you build the frontend.
Modelling tips
- One model per kind of thing. Product, Category, Campaign and Store Location are four models, not one with a type field.
- Use relations rather than repeating data. Point every product at one Category entry, so renaming the category is a single edit.
- Mark required fields properly. It is the cheapest way to stop half-finished entries reaching your storefront.
- Keep slugs stable. They are part of your API surface.
- Model what you render. Fields nobody displays still cost editor time on every single entry.
Want a starting point you can copy? The recipes page has complete model sets for product catalogues, campaign pages and editorial content.