Concepts
Spaces, environments, content types, entries, versions, locales and the three APIs, in the words the rest of these docs use.
Spaces and environments
Section titled “Spaces and environments”A space is a workspace’s container for content: its content types, entries, assets, keys, webhooks and workflows. Everything you do happens inside one space.
An environment is a branch of a space. Every space starts with main; you can create others
(for example staging) to try a content-model change without touching what’s live, compare two
environments, and merge one into another. An alias is a stable name that points at an
environment, so a site can read from production while you switch which environment that is.
Every API path names both: /spaces/{space}/environments/{env}/… for management,
/delivery/{space}/{env}/… and /preview/{space}/{env}/… for reading.
Content types and fields
Section titled “Content types and fields”A content type describes one kind of content (an article, a product page, an author) as an
ordered list of typed fields. Each field has an apiId, a type, and flags for whether it is
required, localized or unique. One field is the display field: the entry’s title in lists and
pickers.
Content types are versioned too: changing one makes a new draft definition, and publishing it makes the change live. See Content modeling.
Entries and versions
Section titled “Entries and versions”An entry is one piece of content of a given type. Saving an entry never overwrites it: it appends a new immutable version. Publishing points delivery at one of those versions. So an entry’s state is derived from two pointers, the latest version and the published one:
| State | Meaning |
|---|---|
| Draft | Never published, or unpublished since. |
| Published | Delivery serves the latest version. |
| Changed | Published, with newer saved edits that are not live yet. |
| Archived | In the trash: hidden from lists and from delivery. |
Any version can be compared with another or restored as a new draft. See Editing and publishing.
Locales
Section titled “Locales”A space has a default locale and a list of others, each optionally falling back to another (for
example fr-CA → fr → the default). Field values are stored per locale:
{ "title": { "en-US": "Hello", "de-DE": "Hallo" } }. A field that isn’t localized still uses
this shape, with one value under the default locale, so reading and writing look the same for
every field. Ask the Delivery API for one locale and it resolves the fallback chain for you.
Assets and references
Section titled “Assets and references”An asset is a file (an image, a PDF, a video) with a localized title and description. Files go straight to object storage through a short-lived upload URL; they never pass through the API. Assets are published like entries.
A reference is a Link field pointing at another entry or an asset. Publishing checks that
what an entry links to exists, delivery can embed linked entries in the response, and the admin
can show what links to any entry.
Releases, workflows and reviews
Section titled “Releases, workflows and reviews”- A release groups entries and assets that should go live together, and publishes them as one unit, now or at a scheduled time. See Releases and scheduling.
- A workflow routes entries through validation, policy checks, approvals and AI steps. See Workflows.
- An agent review is an AI proposal waiting for a person to approve or reject it. See Approvals and reviews.
The three APIs, and MCP
Section titled “The three APIs, and MCP”| API | Base path | For |
|---|---|---|
| Management (CMA) | /spaces/{space}/… |
Modeling, authoring, publishing and administration |
| Delivery (CDA) | /delivery/{space}/{env} |
Published content, search, GraphQL, live updates |
| Preview (CPA) | /preview/{space}/{env} |
Draft content, for previews and staging sites |
Each takes a bearer token: an API key of the matching kind, whose scopes decide what it may do. The MCP server exposes the same operations as tools for AI agents, with the same keys and the same checks. See API keys and access and MCP server.
Events
Section titled “Events”Publishing, unpublishing and other changes emit events such as entry.published. Each event
is recorded in the same transaction as the change, so it is sent if and only if the change
happened. Events drive webhooks, cache refreshes, search indexing and
workflows that start on a change.