Content architecture

A content type is the model for a kind of entry: the extra fields its entries carry beyond the title, slug and body. To create one, choose Architecture → Content Types in the sidebar, then New type. Only the name is required: without one, Content shows "Give the content type a name first." Choose Create type to add it.

• Name: what the type is called, like Article.
• Key: filled in from the name, in lowercase with underscores. Each key is used once in the project.
• Icon: the name of a Lucide icon, like FileText.
• API ID: the type's name in delivery API addresses. Leave it blank and Content makes it from the key, in lowercase with dashes, along with a plural for the type's list, like articles. Changing it later breaks existing API addresses.

Changing content types needs the Manage content types, fields and blocks permission, which the Owner and Admin roles have.

Every entry has one of four types: Article, Page, Guide or Doc. An entry follows the content type whose key or name matches its type, ignoring case. So a content type named Article, or with the key article, gives its fields to every Article entry. A content type whose name and key match none of the four has no entries.

Entries fill in their type's fields in Editorial → Structured Editor, which checks each value against the field's rules before it saves. Architecture → Validation Rules checks every entry at once. A content type created after its entries exist picks them up straight away.

Architecture → Content Types lists the project's content types by name. Each row shows the type's name, key, number of fields and list name in the delivery API, then its icon. The figures across the top show Content types, With fields (types with at least one field), Total fields and Avg. fields per type. Search matches names and keys.

Each row's ⋯ menu has Edit, which opens the same dialog with Save changes, and Delete. Content asks you to confirm a delete. The type's fields go with it, and a deleted type can't be restored.

Fields are the typed values that entries of a content type carry. Choose Architecture → Field Schemas, pick the type from the menu at the top, then choose New field. New field stays turned off until the project has a content type.

• Label: the name editors see. It's the only required field.
• Key: filled in from the label. A key starts with a letter, uses only letters, numbers and underscores, and runs to 64 characters at most. It's used once per type, and these keys are reserved for the delivery API: id, documentId, slug, locale, type, status, publishedAt, createdAt, updatedAt, meta and localizations.
• Data type: Text (the default), Number, Boolean, Date, Reference, Rich text, Enum, JSON or Media. A Media field holds an asset from Content → Assets.
• Position: the field's place in the type's order. New fields go last.
• Localized: No or Yes. Yes marks a field whose value varies per locale.
• Options: for an Enum field, the allowed values separated by commas, like free, pro. At least one is required.
• Delivery: Delivered (the default) or Private. Private fields never appear in delivery API responses.
• Validation rules (JSON): the field's rules.

Choose Create field to add it.

A field's rules are written as JSON in Validation rules (JSON), like { "required": true, "maxLength": 120 }. Content understands these rules:

• required: set to true, the field needs a value.
• minLength and maxLength: the fewest and most characters in a text value.
• pattern: a regular expression a text value must match.
• min and max: the smallest and largest value of a Number field.
• multiple: set to true, a Media or Reference field returns a list in the delivery API instead of a single value.

Boolean fields also have to be true or false, and Enum fields one of their options. JSON and Media values aren't checked for length or pattern. Rules that aren't valid JSON can't be saved: Content shows "Validation rules must be valid JSON."

Architecture → Field Schemas shows the fields of the type picked in the menu at the top, in position order. Each row shows the field's label, key, position and flags (required, localized or private), its data type and its rules. The figures across the top describe that type: Fields, Required, Localized and With rules. Filter by data type, which starts on All Data Types, and search labels and keys.

Each row's ⋯ menu has Edit, which opens the same dialog with Save changes, and Delete. Delete removes the field straight away, without asking. Changing fields needs the Manage content types, fields and blocks permission.

Reusable Blocks keeps a library of named content chunks, like a hero, a quote or a call to action. To add one, choose Architecture → Reusable Blocks, then New block. Only the Name is required. The Key fills in from the name, and Schema (JSON) describes the shape of the block's data. Choose Create block.

To record that an entry uses a block, pick the entry under Instances on entry, then pick the block from Pin a block. Each pin is listed with its position, and the trash icon beside it removes it straight away. Pinning needs the Edit an entry or page permission.

The figures across the top count Reusable blocks, Instances here on the selected entry, Entries and blocks With schema. Each block's ⋯ menu has Edit and Delete. Deleting asks you to confirm first, takes the block's pins with it and can't be undone. Changing blocks needs the Manage content types, fields and blocks permission.

A reference is a one-way link from one entry to another, under a field key such as related. To add one, choose Architecture → References, pick the entry in the menu at the top, then choose Add reference. Pick the entry to link to in Link to, set the Field key (it starts as related) and choose Add reference. An entry can't reference itself.

The screen shows two lists for the selected entry: Outgoing, the entries it links to, and Incoming, the entries that link to it. The trash icon on a row removes that reference straight away. The figures across the top count the project's Entries, the selected entry's Outgoing and Incoming links, and its distinct Link fields.

When the field key matches a Reference field on the entry's content type, the delivery API returns the linked entry in that field when a request asks for it. Adding and removing references needs the Edit an entry or page permission.

Architecture → Validation Rules checks every entry's field values against its content type's rules and lists the problems. It doesn't change anything: fix values in Editorial → Structured Editor, then choose Re-run.

• Invalid: a value breaks a rule, with a message such as "Price is required." or "Price must be at least 0."
• No schema: no content type matches the entry's type, so there's nothing to check.

The figures across the top count Entries checked, Violations, No schema and Rules. Switch between All, Invalid and No schema, and search entries, fields and messages. With no problems, the screen shows "Everything validates". The Rule catalog lists every field of every type with its rules.

A taxonomy is a vocabulary, such as topics or tags, whose terms you attach to entries. To create one, choose Architecture → Taxonomies, then New taxonomy. Only the Name is required, and the Key fills in from it. Hierarchical starts as Flat (tags); pick Hierarchical (parent / child) for terms that nest. Choose Create taxonomy.

Pick a taxonomy from the menu at the top to work with its terms. Under Terms, type a label, then press Enter or choose Add. In a hierarchical taxonomy, pick the parent term first, or leave No parent. Content makes each term's slug from its label, and a slug is used once per taxonomy. The trash icon beside a term deletes it straight away.

To tag an entry, pick it under Assign to entry, then pick a term from Assign a term. The × on an assigned term removes it from the entry. Topic journey stages in Personalization use these terms.

Deleting a taxonomy from its ⋯ menu happens straight away, without asking. Changing taxonomies and terms needs the Manage content types, fields and blocks permission, and tagging entries needs Edit an entry or page.

Localization lists the languages the project publishes in. To add one, choose Architecture → Localization, then New locale. Code, a language code like de or en-IN, and Label, like German, are both required, and each code is used once. Optionally fill in Fallback code, and set Default to Yes for the project's main locale. Choose Create locale.

Each locale's ⋯ menu has Edit, Make default and Delete, which happens straight away, without asking. The delivery API uses the default locale when a request doesn't name one.

A locale version of an entry is a separate entry that shares its slug root: the same slug with a different locale, or the slug followed by -- and the locale code, like getting-started--de. Coverage lists each slug root with the locales it has, and you can search it by slug root. The figures across the top show Locales, the Default locale, Missing default (slug roots without a default-locale version) and Slug roots.

External Sources keeps a list of the feeds and APIs your entries come from. To add one, choose Architecture → External Sources, then New source. Only the Name is required. Type is API (the default), RSS, CSV or CMS. URL holds the endpoint, feed address or connection string, and Status starts as Disconnected. Choose Create source.

A source's status is Connected, Syncing, Disconnected or Error, and you set it by hand: in the dialog, or with Connect and Disconnect in the source's ⋯ menu. The figures across the top count Sources, Connected, Syncing and Needs attention (Error or Disconnected). Filter by status, and search names and URLs. Delete asks you to confirm first, and a deleted source can't be restored.