Skip to content
CM Box Documentation

Architecture overview

CM Box is an enterprise content management and site-building platform. As an integrator, you interact with it through its REST API, per-repository GraphQL endpoints, and webhooks. This page gives you the mental model behind those surfaces.

Services

Section titled “Services”

A CM Box deployment runs as cooperating services:

Service Role
Application The web application and REST API
GraphQL Apollo Server exposing one endpoint per content repository
Queue workers Background jobs: media rendition conversion and webhook delivery
Web Front-end proxy in front of the application

Content, configuration, and search indexes are stored in Redis (with the Search and JSON modules) as the primary database. Binary files live in a configurable storage backend: OCI Object Storage, Azure Blob Storage, or Oracle WebCenter Content.

Request flow

Section titled “Request flow”

Every API request follows the same path:

Request → Middleware (JWT auth) → Route → GraphQL → Redis Search → Response

Authentication happens in middleware before your request reaches any route: requests carry a JWT, and the permissions attached to your user or service account determine which operations succeed. See the REST API reference for the permissions each endpoint requires.

Content repositories (multi-tenancy)

Section titled “Content repositories (multi-tenancy)”

A CM Box instance hosts one or more content repositories — independent namespaces each with its own content types, items, and search indexes. Repositories matter to you in two ways:

  • GraphQL — each repository has its own endpoint at /api/graphql/:repo, with a schema generated dynamically from that repository’s content types.
  • REST — repository-scoped endpoints take the repository as a parameter.

GraphQL conventions

Section titled “GraphQL conventions”

Generated schemas are read-only and follow consistent naming:

  • Single item: get<Type>(id: ID, slug: String, settings: QuerySettings)
  • Multiple items: items(settings: QuerySettings)

Writes go through the REST API. See GraphQL API for details and examples.

Content versioning

Section titled “Content versioning”

Items move through draft, published, and specific version states, tracked by the status field and version flags. When querying, choose deliberately between:

  • latest — the most recent version, including unpublished drafts
  • latestPublished — the most recent published version, which is what site visitors see

Reserved field names

Section titled “Reserved field names”

Content types cannot define fields with names the platform manages itself, such as id, slug, name, type, and status. The full list is in the content model documentation.

Section titled “Related”