Field types

A content type is a set of typed fields. This page is the reference for each type — what it stores, the options it accepts, and whether you can filter and sort on it through the headless API. To learn how to add fields in the admin, see the content types and fields guide.

Every field, whatever its type, has a name (the editor-facing label), a slug (its key in the document's data and in the API), a position (its order on the form), and a required flag. The options below are in addition to those.

Editable types

Text

One line of plain text. Options: a minimum and maximum length, and a default value. Filterable and sortable.

Rich text

A formatted passage — headings, links, lists, and inline marks — edited with the same inline toolbar as a text block and stored on the wire as Portable Text, so consumers receive a structured shape rather than HTML. Options: a minimum and maximum length. Filterable and sortable.

Number

A whole or decimal number. Options: a minimum, a maximum, an integer-only switch, and a default. Filterable (equality match only — there are no range comparisons) and sortable.

Boolean

True or false. Option: a default. Filterable and sortable.

Date

A calendar date. Options: a default-to-today switch that pre-fills new documents with the current date. Filterable and sortable.

Media

An image chosen from the Media library, stored as a reference to the media entity. Uploads are image-only in v1 — magic-byte validation rejects non-image files — so there is no per-field kind filter; every media field accepts images. Options: whether the field is required, and a maximum size. See the media guide for how uploads and the picker work.

Reference

A link to another document, stored as that document's id. Option: a target collection that scopes which documents can be chosen. The API can resolve the reference to the target's title and permalink.

Experimental types

Three structured types persist and read cleanly but are gated in the content-type builder, because the visual sub-field-schema builder is on the roadmap. They appear in the picker marked "experimental — not yet editable" and cannot yet be added to a content type. Data already stored in them is preserved, and none of the three can be used as filter targets through the API.

• Repeater — a list of repeating sub-fields, stored as an array of objects (a recipe's ingredients, a list of links). Repeater fields that already exist are fully editable on the document form: add, remove, and reorder rows inline. Only creating a new one is gated.
• Group — a named cluster of sub-fields, stored as a single object. No editor yet.
• Block — a rich content area built from blocks, stored as a block array. No editor yet; the document body block editor is unaffected and fully available.

Filtering and sorting

On the headless list endpoint you can filter by a field with ?field.{slug}=value and sort with ?sort=field.{slug} (prefix a minus for descending). Text, rich text, number, boolean, date, media, and reference fields are all eligible for both. The exceptions are the structured types: block, repeater, and group fields cannot be used as filters, and block fields cannot be used for sorting. An unfilterable or unknown field returns a 400. The headless API reference covers the full query grammar.