The admin is a single-page React application served alongside the API. It holds
no secrets and talks to /api on the same origin with a session cookie.
The shape of it
A left sidebar beside the work area. The sidebar is collapsible — press ⌘B (or Ctrl+B) to hide it — and on a narrow screen it becomes an overlay drawer.
Almost everything happens inside a workspace. Choosing one puts you at
/workspaces/:id/..., and the sidebar changes to that workspace’s navigation:
Content, Media, Insights, and the Agents view when the copilot is enabled.
Where things live
| Area | What it is |
|---|---|
| Home | Recent activity, and whatever the installed plugins contribute |
| Content | The content library — collections and pages, and the entry editor |
| Saved views | Named slices of a collection’s list — filter, sort, columns — private or shared, in the library’s rail |
| Alarms | The workspace’s content rules and the records they flag |
| Media | The asset library for the workspace |
| Insights | A dashboard of content, media and translation widgets |
| Agents | The full-page copilot conversation view |
| Workspaces | The list of workspaces, and the create wizard |
| Members | People, invitations, roles, sessions |
| Audiences | Reader segments for the public API, and where each is offered |
| API Tokens | Bearer credentials for the public API |
| Webhooks | Outgoing endpoints, their delivery log, and the test ping |
| Activity | The audit log |
Workspaces, Members, Audiences, API Tokens, Webhooks and Activity are global — they sit outside any one workspace, because they are about the installation rather than about a body of content. Webhooks and API Tokens are administrator-only.
The three regions of a page
Most working pages are built from the same three parts.
The top bar carries the breadcrumb and the page’s actions. Actions live there rather than in the panel because the panel can be collapsed away completely, and a record you cannot save is a trap.
The work area is the page itself — a table, an editor, a dashboard.
The properties panel on the right holds metadata and per-record widgets. It collapses, its state is remembered, and when it is collapsed a reopen button appears in the top bar. Only pages that register a panel have the column at all.
Keyboard
| Shortcut | Does |
|---|---|
| ⌘K / Ctrl+K | Open the content search palette, anywhere in a workspace |
| ⌘B / Ctrl+B | Toggle the sidebar |
| ⌘J / Ctrl+J | Toggle the docked copilot window |
| Esc | Close the open dialog, menu or palette |
Everything is reachable by keyboard. The admin holds itself to WCAG 2.1 AA, with axe scans and a keyboard walk in its own end-to-end suite — see accessibility.
Permissions shape what you see
Your role decides which navigation entries appear and which actions are offered. A viewer does not see a Publish button; a contributor does not see Members.
The interface hides what you cannot do rather than showing it disabled, with one exception: an action you could take on a different record stays visible so the page does not appear to change shape as you move around it. The server enforces all of it regardless — hiding a control is a courtesy, never the boundary. See roles and permissions.
Refusal, absence and failure are three different things
Worth knowing when something looks empty, because the admin is careful to distinguish them and the distinction is usually the answer:
- Empty — the query ran and there is nothing here. You get an empty state inviting you to create something.
- Refused — you do not have permission. You get a message saying so.
- Failed — the request errored. You get an error with a retry.
A blank area with no message is a bug, not one of these three.
Theme
Light, dark or system, set per user in Preferences on your own user page. The choice is stored server-side against your account, so it follows you between browsers, and it is applied before first paint so there is no flash.