Content Types ​

Every page must have exactly one content type. The type is fixed at creation and determines the page's required sections, title format, and placement in the site. A page that mixes two content types must be split into separate pages.

Content type taxonomy ​

TypeRequired per product area?Primary audience
OverviewYesDevelopers discovering a product area
Get StartedYesDevelopers starting integration
ConceptAs neededDevelopers needing background knowledge
How-to GuideAs neededDevelopers completing a specific task
Implementation GuideAs neededDevelopers building end-to-end integrations
ReferenceAs neededDevelopers looking up values or limits
ChangelogYes (site-wide)All developers tracking platform changes
FAQ / TroubleshootingAs neededDevelopers who are stuck
API Endpoint DocPer endpointDevelopers making specific API calls

Overview ​

Purpose: Welcome developers to a product area and orient them.

Required sections:

  • One-paragraph product description — what it does and when to use it
  • Key capabilities (bullet list or table)
  • Next steps / navigation links to child pages

Rules:

  • Must be the first page (index.md) in any nested navigation section
  • Do not bury setup instructions here — link to Get Started
  • If the overview adds no value beyond a table of contents, remove it and promote child pages directly

Title format: noun phrase matching the product area — "Market Data", "Trading", "Quote API"

Get Started ​

Purpose: Take a developer from zero to their first working integration.

Required sections:

  1. Prerequisites (account, permissions, installed tools)
  2. Installation / setup steps (numbered)
  3. A minimal working example
  4. Next steps (link to deeper guides)

Rules:

  • Must exist at the top level of every major product area
  • Steps must be numbered and actionable — no vague guidance
  • The working example must actually run without modification beyond credentials
  • One path only — pick the recommended approach (OAuth, not legacy API key as the primary example)
  • Do not embed reference tables (environment variables, legacy API key details) inline — link to a dedicated Reference page instead
  • A Get Started page over ~400 lines is a signal that reference content must be extracted

Title format: "Get started with [product area]" or plain "Get Started"

Concept ​

Purpose: Explain background knowledge developers need before using a feature.

When to create: When a term, behavior, or design decision requires explanation that does not fit inline in a how-to — for example: "WebSocket connection model", "Quote subscription model", "Order types".

Required sections:

  • A clear definition in the first paragraph
  • How it relates to the developer's work
  • Links to related how-to guides

Rules:

  • No step-by-step instructions — concepts explain, they do not instruct
  • Keep to one concept per page; cross-link related concepts

Title format: noun phrase — "Quote subscription model", "Order lifecycle"

How-to Guide ​

Purpose: Step-by-step instructions for a specific, bounded task.

Required sections:

  1. Prerequisites
  2. Numbered steps
  3. Expected result

Rules:

  • Each step = one action + its expected outcome; never multi-action steps
  • Code examples must be complete and runnable for the target language
  • Do not explain concepts inline — link to a concept page instead

Title format: imperative verb phrase — "Subscribe to real-time quotes", not "Subscribing to quotes"

Implementation Guide ​

Purpose: End-to-end walkthrough for achieving a specific integration goal that spans multiple API areas.

Examples: "Build a real-time quote dashboard", "Automate a DCA strategy with the Trade API".

Required sections:

  1. What you'll build (2–3 sentences + diagram if helpful)
  2. Prerequisites
  3. Numbered implementation steps
  4. Complete working code
  5. Next steps

Rules:

  • Scope to a concrete outcome, not a feature tour
  • Longer than a how-to — but keep it focused on the stated goal

Title format: imperative verb phrase describing the outcome — "Build a real-time quote dashboard"

Reference ​

Purpose: Enumerate values, limits, error codes, field definitions, or configuration options.

Rules:

  • Table-first format — minimize prose
  • Keep in sync with openapi.yaml for anything covered by the spec
  • Do not duplicate API Reference content here; link to it instead

Changelog ​

Purpose: Record platform-level changes visible to developers.

Rules:

  • One entry per date (## YYYY-MM-DD), newest first
  • Each entry: 1–3 bullet points, user-facing value only (no internal jargon)
  • CLI releases: sub-heading ### CLI vX.Y.Z with link to GitHub release
  • All three language versions updated simultaneously

FAQ / Troubleshooting ​

Purpose: Answer the top questions and unblock common failure modes.

Rules:

  • FAQ: question as heading (### Why does X happen?), concise answer below
  • Troubleshooting: symptom → cause → fix structure
  • Keep entries short; if the fix requires multiple steps, link to a how-to

API Endpoint Doc ​

Purpose: Technical reference for a single HTTP or WebSocket API endpoint.

Required sections (in this order):

  1. One-sentence description in active voice (third-person present: "Returns…", "Filters…", "Lists…")
  2. <CliCommand> block — if a CLI command maps to this endpoint
  3. <SDKLinks> component — required on all API endpoint pages (see API Reference Standards)
  4. ## Request — HTTP method + URL table; then ### Parameters table (name / type / required / description); then ### Request Example using <Tabs groupId="programming-language"> (see Writing Guidelines) with all supported SDK languages
  5. ## Response — response headers, ### Response Example (JSON), ### Response Status (status code table)
  6. ## Schemas — field definition tables for complex nested types

Rules:

  • One endpoint per page — never combine two endpoints on a single page
  • All parameter names, types, and required/optional flags must match openapi.yaml exactly
  • Do not invent parameters or response fields not in the spec

Title format: imperative verb + object noun — "Get static quote", "Submit order"

Valid frontmatter fields: title, id, slug, sidebar_position, sidebar_icon

Deprecated frontmatter fields (from a legacy Slate-based system; remove when editing existing pages):

language_tabs, toc_footers, includes, highlight_theme, headingLevel