Core concepts
Understand workspaces, projects, spaces, pages, the page lifecycle, reader sites, and the ways to automate Doxbrix.
This page explains the objects you work with in Doxbrix and how a page moves from a draft to a live site. Read it before your first project so that the labels in the editor, settings, and CLI make sense.
The object model
Doxbrix organizes documentation in four nested levels: a workspace contains projects, a project contains spaces, and a space contains groups and pages.
Workspace
A workspace is your organization's account. It holds members, roles, billing, single sign-on (SSO), the AI policy, and all your projects.
When you sign in for the first time, Doxbrix creates a workspace for you automatically and makes you its owner. The workspace is named after your profile, for example Alex Rivera's Workspace. You can rename it later in workspace settings. Before you use the app, the owner chooses a plan for the workspace; see Create an account and choose a plan.
Members join a workspace by invitation and receive a role, such as owner, admin, or editor. The role decides what a member can change. Roles and permissions lists every role.
Project
A project is one documentation site. Each project has its own name, site address, branding, reader access setting, and content. A new project's site address follows the pattern {slug}.doxbrix.app, for example acme-docs.doxbrix.app, and you can connect a custom domain later.
Projects come in two kinds:
| Kind | Where content lives | Created with |
|---|---|---|
| Native project | You write and edit pages in the Doxbrix editor. | Create new docs, Import docs into Doxbrix, or Create docs with Doxloop |
| Connected project | Your existing docs-as-code site stays in its own generator; Doxbrix builds and hosts it and adds its AI assistant. | Host existing docs with Doxbrix |
The rest of this page describes native projects. For connected projects, see Host an existing docs site.
Space
A space is a top-level section of a project with its own navigation tree. Use spaces to separate large areas that readers switch between, such as Guides, API reference, and Release notes. A space can also contain sub-spaces.
Group and navigation items
A group is a folder inside a space's navigation. Groups hold pages and other groups. In the editor's content panel, the New page, group, or space control opens a menu with Add page, Add group, Add API reference, Upload PDF, Add space, and Add sub-space.
Besides pages and groups, a navigation tree can contain labels (non-clickable section text), dividers, external links, and API reference entries. Organize spaces, groups and navigation shows how to build and reorder the tree.
Page and blocks
A page is one article. In the block editor, a page is made of blocks, such as paragraphs, headings, code, callouts, and images. You can type blocks, insert them with slash commands, generate a page with AI, or import a Word, Markdown or PDF file. Blocks and slash commands reference lists every block type.
The page lifecycle
Every page has a status. The status decides whether readers can see the page and whether you can edit it directly.
| Status | What it means | What you see |
|---|---|---|
| Draft | Work in progress. Readers cannot see it. | Submit for review or Publish in the editor's top bar |
| In review | Waiting for a reviewer. | Approve & Publish and Reject for reviewers |
| Published | Live on the reader site and locked for editing. | The banner This page is published and locked for editing. and an Edit page control |
| Unpublished | Removed from the reader site by an owner or admin. | The page no longer appears to readers |
Owners, admins, and editors can submit a draft. Only a draft can be submitted; submitting any other status fails with Only draft pages can be submitted for review.
Approval policies
Each project decides whether publishing needs approval:
- Project review: owners and admins approve pages.
- Section review: editors can approve too.
- No required approval: the editor shows Publish instead of Submit for review, and the page goes live immediately.
When approval is required, submitting moves the page to In review and notifies the assigned reviewer, if there is one. When a group contains more than one draft, a split button lets you submit or publish this page only or the whole section. Doxbrix saves a version of the page each time it enters review or is published, so you can compare changes in version history.
Page lifecycle and approval policies and Submit, review and approve pages cover these steps in full.
Reader sites
Published pages make up the project's reader site. Readers see your navigation, search, a theme toggle, and the Ask AI assistant, which answers questions from your published content. A site is public by default; you can make it private to restrict who can open it. Readers can also leave feedback and request articles, which appear in the feedback inbox.
After publishing, Docs Health scores quality and lists issues, and analytics shows what readers view and ask.
Automation surfaces
Everything you do in the browser also has a programmatic route. All of them authenticate with a personal access token that starts with dxb_.
| Surface | Use it to | Learn more |
|---|---|---|
dxb CLI | Author pages locally as MDX, check them, and push them from a terminal or CI. | Install the dxb CLI |
| Git sync | Keep a project in sync with a GitHub or GitLab repository. | Sync a project with a Git repository |
| REST API and SDK | Read and change projects and pages from your own code. | REST API reference |
| MCP server | Let AI agents such as Claude Code read and edit your docs. | Connect AI agents with the MCP server |
