Content Types
Understand the schema (blueprint) behind your content — fields, types, and how they shape the data you fetch.
Content Types
A Content Type is the schema (blueprint) for your content in Atlas CMS — like a table definition in a relational database. It declares the fields that make up an entity. The actual data you store against a content type is called an Entry.
You can create content types in the Atlas dashboard or through the Management API. This page explains the concepts behind content types and the field types available, so you know what to expect when reading entries through the Public API.
Managing content types
The Management API can author content types with a key carrying the schema:write
scope — create a type, add fields, edit labels, reorder them, and delete a type that has
no entries. This is what lets an AI agent using the
MCP server build a schema without a human stepping in.
Changes that alter the shape of already-stored data are dashboard-only: renaming a
field, changing its field_type, toggling localizable / is_unique / required,
editing validation, deleting a field, deleting a type that has entries, and toggling
is_block. Those need a human to see the impact preview first — a rename, for example,
leaves every existing entry with data under the old key.
The split is enforced by the request shape of the /manage endpoints: the excluded keys
are absent from them, not merely ignored. See
Authentication → Scopes.
Fields
Every field on a content type has these properties:
| Property | Description |
|---|---|
name | Machine name used as the key in entry data (e.g. full_name). |
label | Human-readable label shown in the dashboard. |
field_type | The kind of value stored (see below). |
required | Whether the field must have a value. |
localizable | Whether this field can have per-locale values. |
filterable | Whether list queries can filter by this field. |
sortable | Whether list queries can sort by this field. |
Field Types
field_type | Use for | Example value in API response |
|---|---|---|
text | Short, single-line text | "John Doe" |
textarea | Plain multi-line text | "Short bio..." |
richtext | Long-form formatted content (Editor.js JSON by default; if the field is named body, request body_html or body_text via ?fields=) | { "blocks": [{ "type": "paragraph", "data": { "text": "..." } }] } |
number | Integer or decimal | 42 |
boolean | True/false flag | true |
date | Date and time | "2026-01-01T00:00:00Z" |
select | One choice from a fixed list | "published" |
image | Media file (resolved to full object) | { "url": "https://cdn…/photo.webp", "width": 1200, "height": 630, "alt": "…" } |
relation | Entry of another content type (resolved one level deep) | { "slug": "arya-santoso", "data": { "name": "Arya Santoso" } } |
content_type_reference | Reference to a content type | "<content-type-id>" |
Block Types
A content type with is_block: true is called a block type. Block types are
used as reusable building blocks inside Pages — each block renders as a
section of a page (hero, feature row, CTA, etc.) rather than standing alone as an
entry. Their fields follow the same rules and field types as regular content types.
Discovering a Content Type's Fields
Because every workspace defines its own content types, the field names inside data
vary per workspace. Use the Schema Explorer on the Entries
page to fetch a content type's real fields and generate an example payload matching
that type's schema.
Next Steps
- Entries — how to fetch entry data through the Public API.
- Localization — mark fields as localizable and read locale-specific values.