Content

The Content block is headless content management for your product: you define content types, editors create entries against them, and your application reads them over REST or GraphQL. Assets — images, documents, video — live in content stores alongside the entries that reference them.

“Headless” is the important word. The block owns modelling, storage, versioning and delivery; it does not own presentation. Your front end decides what a page looks like.

The model

  Content App              a bounded content space (a site, a product area)
      ├── Content Types    the schema: fields, types, validation
      │     └── Entries    the actual content
      └── Templates        reusable content structures

  Content Store            asset storage
      ├── Folders
      └── Assets           images, documents, media

A content app is the unit of separation. Marketing pages and in-product help are usually two apps rather than two content types in one app, because they have different editors, different lifecycles and different consumers.

Security

Content entries are entities, and they are protected by the same pipeline as the Data API — the same access rules, the same row-level security, the same field-level permissions and compliance directives.

That is worth stating because it is easy to assume a content service is a softer surface than a data service. It is not: an entry is a row, a content type is an entity, and everything on Access rules, Row-level security and Compliances applies here unchanged.

Two properties worth knowing when you write those rules:

Field-level fields: rules are evaluated. A rule restricting who may read or write an individual field is applied to content entries exactly as it is to any other entity.

Row-level rules fail closed. A rule that cannot be compiled into a query predicate denies access rather than passing the query through, so a rule you have written is either enforced or it stops the request — never silently absent.

Configure access rules per content app as part of setting it up, and verify them against what each consumer expects to see. A content app that serves a public website and one that serves internal help have different answers, and the rules are where that difference lives.

Next

• Usage — content types, entries, GraphQL, assets and templates
• Operations — access control, storage and what to watch