OndrosCore Concepts
How Ondros organizes content — familiar if you've used Contentful, with a few extras.
Organizations (accounts)
The account is the top-level tenant: it owns members, roles, billing, SSO configuration, and spaces. Users can belong to several accounts and switch between them; every API token is scoped to exactly one account.
Roles: ORG_ADMIN, SPACE_ADMIN, EDITOR, AUTHOR, VIEWER (plus custom
roles), assigned org-wide or per space. Every endpoint checks a capability
derived from your role.
Spaces
A space is one project: content model + entries + media + locales + API keys + webhooks. Plans limit how many spaces an account can have.
Environments
Each space contains isolated environments (master, staging, …).
Content types and entries are environment-scoped, and cloning an environment
copies both — with reference ids remapped — so you can trial a model change on
a clone before it touches production.
Content types & fields
A content type is a schema of typed fields:
| Type | Notes |
|---|---|
text, longtext, richtext | strings; rich text stores HTML |
number, boolean, datetime | scalars |
select | enum of allowed values |
media, media_many | links to media assets |
reference, reference_many | links to entries — the building block of assemblies |
json | arbitrary structured data |
slug | URL segment — adding one makes the type's entries pages |
Any field can be localized (stored as {locale: value} maps) and carry
validations (required, min/max length, pattern, allowed content types for
references).
Pages and blocks
A content type is addressable by URL because its model contains a slug field
— nothing else marks the difference. landing_page and article have one and
get their own URLs; reusable blocks like hero and card don't, so authors
are never asked for a slug when creating one. A type may have at most one slug
field, and the editor offers to add it when you create the type.
This is also what decides how an entry previews: a page opens at its own URL, a block opens inside a page that references it. See Code Sync.
Entries & workflow
Entries hold draft fields and, separately, the frozen published_fields
snapshot. The workflow is draft → in_review → published → archived; the
delivery API only ever sees the published snapshot. Every save creates a
version you can diff and restore from the history panel.
Locales & fallbacks
Locales are first-class rows per space, picked from an ISO catalog. Each locale
may define a fallback (e.g. hi-IN → en → default), and the delivery API
walks that chain per field. Request locale=* to get raw locale maps.
API keys — delivery vs preview vs management
| Key | Prefix | Grants |
|---|---|---|
| Delivery | cms_del_ | read published content in its space |
| Preview | cms_pre_ | read drafts + published (adds status info) |
| Management | cms_mgm_ | full space CRUD from scripts/CI |
Keys are hashed at rest, shown once at creation, and can be restricted to specific environments. User sessions use short-lived JWTs with refresh rotation instead.
Continue with the SDK Reference or the raw API Reference.