Reference

A reference page enumerates the facts about one nameable surface, such as a file format, a command, or a set of limits, completely and in a uniform structure. The tone is plain and straightforward.

Reach for a reference page when a reader needs to look up exact facts about one surface. Two laws govern the type: completeness, because a missing entry breaks a reference the way a missing word breaks a dictionary, and uniformity, because every entry answers the same questions in the same order. It is not:

• A how-to. Reference describes, never instructs. A "to do this, first ..." entry means you extract a how-to and link it.
• A concept. Opinion and rationale live on the concept page, so one orienting sentence with a concept link is the whole prose allowance at the top.
• A dumping ground. "Miscellaneous" is where facts go to become unfindable. Keep one surface per page and mirror the product's own structure.

For the full comparison, refer to Content types. For live examples, refer to Common Cf-Polished statuses and Logpush API configuration.

• Title: the surface's name as the reader searches for it, such as "CLI commands", "Event types", or "Limits". Use "Reference" for a single standalone page, use nouns for a section with child pages, and add "reference" to a noun only when the bare name is ambiguous, as in "Retry policy reference".
• Description: name the entry kinds the surface accepts and the fact categories each entry lists.

Use the Nimbus reference recipe to generate this page. Your coding agent pulls the full page skeleton and self-review checklist, then adapts them to your product:

npx @cloudflare/nimbus-docs add content-reference

yarn @cloudflare/nimbus-docs add content-reference

pnpm @cloudflare/nimbus-docs add content-reference

Adapt the frontmatter the recipe emits to Cloudflare's schema: set pcx_content_type and products instead of the generic fields the recipe emits, such as type.

• Tables are the signature component: a quick-reference table before the entries makes the common lookup zero-scroll. Keep tables simple, because merged cells and meaning-by-layout break both scanning and extraction.
• Definition lines carry the same facts in a fixed order, such as type, default, required, and constraints, bolded or badged consistently across every entry.
• DirectoryListing links the child pages when the reference is a section rather than a single page.
• What does not fit: Steps, Cards, and callouts (a fact that needs a warning usually belongs in the entry as a constraint), plus tabs or accordions that hide entries (a collapsed entry is invisible to search-and-grab readers and to extraction).

pcx_content_type: reference
products:
  - product-a
  - product-b

For more details, refer to pcx_content_type.

A reference is complete or clearly scoped, with nothing in between, so if a subset lives elsewhere the first line says where. Give every fact exactly one source: generate values that live in code or a schema, and where generation does not yet exist, name the source so maintainers know what to diff against. Hand-maintained fact pages such as limits or quotas carry a visible reviewed date. When a surface passes roughly 30 entries, split it along its own seams, such as file layout or command groups, never alphabetically.

• Self-identifying entries. Give every entry heading its full name, such as the dotted path retry.max_attempts rather than max_attempts under a "Retry" heading, so a retrieved chunk carries its own identity.
• Machine-checkable values. State ranges, defaults, and limits as literal values rather than "a reasonable number", and keep examples minimal in fenced blocks with realistic values.
• Nothing hidden. Keep every entry in the open, because a collapsed or tabbed entry is invisible to extraction. The Markdown twin of a reference page is the page.