Stable field IDs
Fields are addressed by ID, not by label. Rename a field in the UI and every template binding and API integration keeps working.
ProductCONTENT MODELING
Your content model. Your data. Never rented.
Define content types the way an engineer would design a schema — not the way a page builder forces you to. Every field carries a stable ID, so templates and integrations survive a field rename instead of silently breaking.
01 / THE PRIMITIVES
Rich field types, not a text box
Short text, rich text, relations, media, enumerations, dates, decimals, JSON, and typed components give you a real content model — the same primitives you’d reach for designing a database schema, exposed to editors as structured fields.
Relations & validation
Relate records to each other and constrain fields at the schema level, so bad data is rejected at entry, not discovered downstream.
Forward-only migrations
Schema changes run with dry-run impact checks and apply forward-only — evolving a content type never resets the records already in it.
02 / COMPOSE, DON’T DUPLICATE
Components and dynamic zones
Build reusable, nested components once, then let editors assemble flexible page bodies from an allow-listed set of blocks — no copy-pasted field groups, no developer ticket to rearrange a page.
Reusable components
Define a component — an address, a pricing tier, a FAQ entry — once, and reuse it across every content type that needs it.
Dynamic zones
Give editors a curated set of blocks to assemble into a page body, without opening the layout up to arbitrary HTML.
Multi-locale fields
Every field can carry per-locale values with a clear default-locale source record, so translation stays structured, not duplicated.
MODEL YOUR FIRST TYPE
Start with one content type.
Define fields, add a component, and see a generated page bound to real data.