Schema – structuring the content

The schema describes the structure of the content. You might also know it as the content model.

Entity type

Each entity type has a unique name. It must start with an uppercase letter and can only contain letters, numbers and underscore, e.g. "Article", "GlossaryTerm".

It's possible to limit an entity type to be admin only, which means that entities of the type can't be published.

By default, entities can be created with any authorization key. This can be restricted with an auth key pattern. E.g. to restrict entities to have the authorization key "none", you can create a pattern named "none" with the regular expression ^none$.

The rest of the entity type is defined as fields. The way the fields are specified is the same for entity types and component types, so you can read about it below.

Component type

Just as entity types, each component type has a unique name, and it has the same naming restrictions.

It's possible to limit a component type to be admin only. A component of that type can't be published. It you want to store a component in an entity that is published, it has to be in an admin only field.

The rest of the component type is defined as fields, which we'll get to now.


Entity types and component types can contain any number of fields.

Each field has a name, which only needs to be unique within the type. The name has to start with a lowercase letter and can only contain letters, numbers and underscore, e.g. "title", "isOpen".

In order to prevent a field from being empty when it's published, it can be marked as required. You can still save an entity with empty required fields, but in order to publish the entity, all required fields must have a value.

Just as you can make a whole type admin only, you can also specify that just a field should be admin only. All admin only fields are hidden from the published entity.

In order to know what kind of data can be stored in a field, each field has an associated field type (Boolean, Component, Entity, Location, Number, Rich text or String).

A field can contain a single value, or a list of values. All items in the list must be of the same field type, e.g. a list of String, or a list of Component.

Some types also comes with more configuration options.


A boolean field can be true, false or not set.


A component field contains a component.

It's possible to restrict which component types can be used in the field.


An entity field contains a reference to an entity.

It's possible to restrict the entity types of the referenced entity.


A location field contains latitude and longitude (using the EPSG:4326/WGS 84 coordinate system).


A number field contains any number, either integer or float.

Rich text

A rich text field contains text with formatting (e.g. bold, italic) and can contain multiple blocks (e.g paragraph, bullet list) and other content. It can also contain components and references to entities.

It's possible to restrict the rich text nodes that can be used.

  • root, paragraph and text are required for all rich text fields
  • list and listitem are needed for bullet, numbered and check lists
  • heading is needed for Heading 1–6
  • entity is needed for references to entities where the entity is embedded (e.g. an image)
  • entityLink is needed for text linking to an entity (e.g. link to an article)
  • link is needed for text linking to a URL
  • component is needed for embedded components
  • depending on your application there might be more node types that are applicable

It's possible to restrict the entity types that can be embedded in the rich text field. This configuration requires entity nodes to be allowed.

It's possible to restrict link entity types, which is the entity types that can be linked to. This configuration requires entityLink nodes to be allowed.

It's possible to restrict component types that can be embedded in the rich text field. This configuration requires component nodes to be allowed.


A string field contains text without any formatting.

A multiline string can contain multiple lines of text.

If an index is specified for string field, it's possible to ensure that the value is unique within that index.

It's possible to specify that the value must match a pattern.

Unique index

Currently there is only support for one kind of index, a unique index. For fields using the same unique index, there can be only one instance of each value. One use case for unique indexes is slugs, where you want to ensure that a certain link only points to one entity.


Patterns are named regular expressions. Each pattern must have a unique name.

Patterns can be used to restrict authorization key values for an entity type, or values in string fields.