Documentation Configuration Reference

Everything that makes a documentation set look and behave the way it does lives in one object on the page type, called documentationConfiguration. This page is the complete enumeration of that object — every key, no omissions — plus the page-type fields around it that change how a set behaves, and the one inheritance rule that explains why a value you can see in the CMS may never reach your site.

How to read this page

One row per field.

Stored form matters more than it sounds. Three of the four appearance values are stored as the complete CSS class name (color-theme-leed), and one is stored bare (charlie) because the build turns it into a template path. Getting this backwards is the most common configuration mistake in the whole object.
Set where is the CMS screen that writes the value. One field is written by the server and should never be typed by hand.
Inherits answers whether a page type falls back to the company-level copy. The answer is almost always display only — see the inheritance rule, which is the single most consequential paragraph on this page.
Read by names what on the published site actually consumes the value, so you can tell what breaks when it is wrong.

Nothing in this object has a schema default. An absent key stays absent, and the consumer’s own fallback — usually do nothing — applies.

The `documentationConfiguration` fields

Field	Type	Stored form	Default	Set where	Inherits?	Gated?	Read by	If unset
`layoutName`	string	bare name — `alpha`, `bravo`, `charlie`	none; the editor seeds `alpha` on a new set	Settings → Page Types → the set → Documentation	display only	no	The layout partial `leed/docs/<name>/base`, and the `docs-layout-<name>` class on `<html>`	Hard failure. Every page in the set renders one line: `documentationConfiguration is missing!`
`colorTheme`	string	full class name — `color-theme-teal`	none; the editor seeds `color-theme-blue`	same panel	display only	Starter, to introduce a name that is not built in	A class on `<html>`; the theme’s `--docs-*` token layer	No `--docs-*` layer. Every token falls through to your site’s own values, then to Leed’s defaults
`codeTheme`	string	full class name — `code-theme-github`	none; the editor seeds `code-theme-github`	same panel	display only	Starter, to introduce a name that is not built in	A class on `<html>`	Highlight.js still emits its token classes, with no rules behind them — code renders unstyled
`font`	string	Tailwind font utility — `font-noto-sans`	none; the editor seeds `font-open-sans`	same panel	display only	Starter, to introduce a name that is not built in	A class on `<html>`	The set inherits whatever font your site sets
`menus.left`	string	a menu id, not a name	none	same panel, Documentation Menu	display only	no	The sidebar, breadcrumbs and previous/next. Also server-side: it is what classifies a menu as a docs menu, what derives the read-only `navMenuId`, and what folder-path recompute keys off	No sidebar, no breadcrumbs, no pager — and the set’s pages get flat URLs with no folder structure
`menus.top`	string	a menu id	none	same panel	display only	no	The header navigation	The header nav renders empty; the build logs `documentationConfiguration.menus.top was not located!`
`menus.bottom`	string	a menu id	none	same panel	display only	no	The footer menu columns	The footer renders only its social row and its copyright line
`searchIndexId`	string	a search-index id	none	Server-written when you create a search index and the set has none	display only	no	The search asset hashes on every page of the set	Search asset hashes come back empty. Do not hand-author this
`startingPage`	string	`pageid:<uuid>`	none	same panel	display only	no	The breadcrumb home crumb, and nothing else	Breadcrumbs render without a home crumb. Nothing else changes
`header.button.text`	string	plain text	none	same panel	display only	no	The header call-to-action label	With `href` also absent, no CTA renders at all. With the object present and the text empty, an unlabeled button renders
`header.button.href`	string	absolute URL or `pageid:<uuid>`	none	same panel	display only	no	The header call-to-action target	As above
`logo.light`	string	a URL or site path	none	same panel	display only	no	The `--nav-logo-url` custom property used by the docs header and footer logo	The logo box renders empty — it is a background image with no image
`logo.dark`	string	a URL or site path	none	same panel	display only	no	The same property inside a dark-scheme media query	Dark mode keeps the light logo
`tabGroups`	object	`groupId → tabKey → entry`	none	Settings → General → Tab Groups, and the set’s own panel	special — see below	no	The tab renderer at build time; separately, the editor’s Tab Group menu reads the company copy	Tabs still render, with the label the author typed and no icon
`openAPI.snippetLanguages`	array	snippet language configs	none; Settings → General seeds cURL, TypeScript, Python and Go	Settings → General	display only	no	The CMS’s OpenAPI import when it generates code samples. The site build does not read it	Generation falls back to the same four languages
`highlighter.extraLanguages`	string array	language names	none	no CMS control writes here	—	—	Nothing at all	Nothing. See the note below

`highlighter.extraLanguages` is present in the schema and read by nothing

Extra Highlight.js languages are real, but they are not configured here. The site build reads them from the workspace’s top-level extended.highlighter.extraLanguages, and Settings → General writes them there — a different object with the same shape. A value placed in documentationConfiguration.highlighter is stored, published, and ignored.

Each language you add also needs a matching src/static/js/hljs-<language>.js file in your site repository. A language with no file logs Extra language <name> not found: <path> during the build and is skipped, so the code block renders unhighlighted rather than failing the build. Adding a language beyond the built-in set is an Enterprise feature; the built-in languages are free on every plan.

A complete stored configuration, as committed

This is the documentation half of a real set — the page type’s data file after publishing. The site-wide half of the same configuration lives in the workspace’s own data file and layers underneath it.

{
  "documentationConfiguration": {
    "layoutName": "charlie",
    "colorTheme": "color-theme-leed",
    "codeTheme": "code-theme-leed",
    "font": "font-noto-sans",
    "logo": {
      "light": "/static/images/logo/leed-logo-p-light.svg",
      "dark": "/static/images/logo/leed-logo-p-dark.svg"
    },
    "menus": { "top": "87cf4837", "left": "leeddocs", "bottom": "IU24ZTE1" },
    "header": {
      "button": { "text": "Start free", "href": "https://app.leed.ai/auth/sign-up" }
    },
    "startingPage": "pageid:f9618447-4ab8-48f6-9b37-73f2e957b88c",
    "tabGroups": {
      "operating-system": {
        "linux": { "title": "Linux", "icon": "fa-brands fa-linux", "order": 0 },
        "mac": { "title": "Mac", "icon": "fa-brands fa-apple", "order": 1 },
        "windows": { "title": "Windows", "icon": "fa-brands fa-windows", "order": 2 }
      }
    }
  }
}

Where the values end up on the published site

Four of the fields become nothing but a class list. The build joins font, then docs-layout- plus layoutName, then colorTheme, then codeTheme, and puts the result on the root element of every page in the set:

<html lang="en" class="scroll-smooth js-focus-visible leed-documentation font-noto-sans docs-layout-charlie color-theme-leed code-theme-leed">

That is the whole mechanism, and it is why the stored forms differ: colorTheme, codeTheme and font are emitted verbatim as classes, so they must be class names, while layoutName is prefixed here and used as a template path elsewhere, so it must be bare. It is also the hook your own CSS attaches to — How Styling Works starts from this element.

Everything else is read by a template: the menu ids by the sidebar, header and footer partials, the logo by a custom property, the starting page by the breadcrumb trail. A template author reaches most of it through a small set of helpers rather than the raw object — those are at Documentation Navigation Helpers.

The inheritance rule, stated once

The mechanism is worth one paragraph, because a developer reading the site repository will otherwise conclude the files are incomplete.

Your workspace serializes to one site-wide data file, and the schema that produces that file does not include documentationConfiguration at all — it carries site title, description, locale, logo, favicon, social accounts, date format, paging, deployment details and the plan tier, and nothing else. Every writer of that file parses the record and replaces the file whole, so a block hand-written into it is deleted by the next settings save, batch publish, or entitlement change. The page-type schema does include the configuration, and serializes it to the set’s own data file at src/<slug>/<last-slug-segment>.11tydata.json. Both files are Leed-owned; hand-editing either one is temporary.

Set the configuration on the page type and let the CMS regenerate the file. What the word “default” does and does not mean on the workspace screen is covered at Default Content Configuration.

The one field that behaves differently

tabGroups needs to exist in both places, and this is not a contradiction of the rule above — it is two different consumers reading two different copies.

The page type copy is what the build reads. A group defined only here renders correctly on your site and is missing from the editor’s Tab Group menu.
The workspace copy is what the editor’s Tab Group menu reads. A group defined only here appears in the toolbar and renders on the site with no titles and no icons.

Define your groups in both, and know that they can drift: the workspace copy propagates down to your documentation and API page types fill-only — a new group is added, a changed title is never overwritten, and a deleted tab is never removed. Tab Groups for Consistent Examples owns the detail.

What the front matter of a published page contains

Each page commits as a block of JSON between --- fences — not YAML — followed by the body. On a hand-authored documentation page the keys that carry real values are title, pageTypeId, pageId, publishedAt, modifiedAt and summary.

Three things developers look for and do not find:

No category and no order. Hierarchy comes from the menu tree, and ordering from an item’s position in it. (order is a real key on a tab-group entry, where it sorts what the editor inserts. The two are unrelated.)
No path. See below.
previewOnly is in the emitted set and defaults to false. It has no CMS control, and if it is ever set the page is excluded from production builds and from indexing.

The complete emitted field list, including the keys a documentation page never populates, is at Front Matter Reference.

Where a page’s URL comes from — and the fields that do not set it

path is not a documentationConfiguration field, not a page-type field, and not an emitted front-matter key. A documentation page’s URL is composed: the page type’s slug, then the slugified name of each docs-menu folder above the page, joined by /, then the page’s own slug. The create endpoint ignores a client-supplied path for a menu-bound documentation page type by design, so the URL can never contradict the menu.

The consequence — that renaming a folder physically moves every page beneath it — is worked through at Folders Set Your URLs.

Page type fields that change how a documentation set behaves

The fields above configure the set’s appearance and navigation. These are on the page type itself and change how the set works.

Field	Type	Default for a docs type	What it changes	Read by	Editable where
`slug`	string	none — you choose it	The first segment of every URL in the set, and the directory the set’s files live in. May nest (`docs/api/1.2.0`) for versioned API sets	The build, for every path in the set	Settings → Page Types, until the set is published
`type`	`documentation`	`api`	`posts`	`documentation`	Which machinery applies. `documentation` and `api` share the docs menu, the docs layout and this configuration object; `posts` shares none of it
`layout`	string	`leed-documentation.hbs`	The Handlebars layout every page in the set renders through. Documentation and API types are always set to the system docs layout	The build	Not meaningfully editable for a docs set
`navMenuId`	string	derived	A read-only projection of `menus.left`. It exists so other parts of the CMS can ask “which menu owns this set?” without reading the configuration object	The CMS	Not client-settable — change `menus.left` instead
`requiredFields`	object	`summary: true`, everything else off	Which fields must be filled before a page can publish	The publish check, in the CMS and over the API	Settings → Page Types
`editorFormattingOptions`	object	inert for docs types	Which editor blocks are available. For `documentation` and `api` types the toggles are not rendered and the flags are not enforced — every block is available	Only `posts` types	Not shown for a docs set
`locked`	boolean	`false`	Content Locked: no new pages, and existing pages become read-only. Only an Administrator or Content Publisher can set or clear it	The CMS	Settings → Page Types
`navMenuLocked`	boolean	`false`	Navigation Menu Locked: the set’s pages cannot change URL through its menu — no reordering, no moving, no folder renames, no removal from the nav. Presentation edits stay allowed	The CMS menu editor	Settings → Page Types
`aliases`	string array	none	Extra URL prefixes that redirect into the set	The build’s redirect rules	Settings → Page Types
`redirectIndex`	string	none	What the set’s root URL does: `first`, `last`, a site-relative path, or an external URL	The build’s redirect rules	Settings → Page Types
`noRender`	boolean	`false`	Suppresses rendering of the set’s pages by the site builder, leaving them for a developer’s own templates	The build	Settings → Page Types
`autolink`	boolean	`true`	Whether the set’s pages participate in automatic keyword linking	The build’s content pass	Settings → Page Types
`includeInFeeds`	boolean	`true`	Whether the set appears in feeds and in the AI-support surfaces built from them	The build	Settings → Page Types
`allowRecommendations`	boolean	none	Whether the set’s pages are eligible as recommendations	The recommendation engine	Settings → Page Types
`sitemapPriority`	number	falls back to `0.99`	The `<priority>` written into the sitemap for the set’s pages	The sitemap	Settings → Page Types
`labelSiteMapPriority`	number	falls back to `0.79`	The same, for the set’s generated label pages	The sitemap	Settings → Page Types

Every page-type field that is not documentation-specific — and the ones above in their non-documentation meanings — is enumerated at Page Type Reference.

Two of the appearance fields are plan-gated on introducing a name that is not built in, which is a narrower rule than it first appears: echoing the stored value, clearing it, or swapping one built-in theme for another passes on every plan. Themes, Fonts and Code Themes has the exact behavior, and the CSS that makes a custom name mean anything.