Skip to main content

Documentation Index

Fetch the complete documentation index at: https://developer.suki.ai/llms.txt

Use this file to discover all available pages before exploring further.

Agent Guidelines for Suki Developer Documentation

Project Type

This is a Mintlify documentation site for Suki’s healthcare AI platform APIs and SDKs.

New Doc Writing Rule

When starting any documentation work, proactively create a todo list of tasks (using the todo tool) and work through them. For doc updates, suggest: review content, check links, verify examples, update dates. Style: Follow the Writing style guide; check headings (sentence-style capitalization), punctuation (no em dashes, Oxford comma), and tone (professional, developer-focused).

Instruction scope (do not assume)

  • Do only what the user explicitly asked. If they asked to check, verify, or investigate, deliver findings (what the repo says, gaps, contradictions). Do not rewrite multiple pages or assert product behavior unless they asked you to update docs or confirmed facts.
  • If something is unclear or needs ground truth not present in the repo (for example, whether a feature exists in a shipped SDK), ask the user for clarity instead of assuming and editing.
  • Broad edits (new sections, cross-cutting claims, many files) require an explicit request or a short plan the user approves.

Git (commit and push)

  • Do not run git commit or git push unless the user explicitly asks to commit and/or push (for example: “commit”, “push”, “commit and push”).
  • When work is done without that request, leave the working tree as-is (or only stage if they asked to stage), summarize changes, and let the user commit when they want.

Build / Development

  • mintlify dev or mint dev — Start local development server
  • mintlify install — Reinstall dependencies if dev server fails
  • Playwright E2E tests live in the separate repo LearningMotors/documentation-testing (run against mint dev or PLAYWRIGHT_BASE_URL staging); no test scripts in this repo

File Structure

  • docs.json — Main Mintlify configuration (navigation, theme, SEO)
  • documentation/ — Platform docs, getting started, guides
  • api-reference/ — API reference and OpenAPI-backed pages
  • web-sdk/ — Web SDK docs
  • mobile-sdk/ — Mobile SDK docs
  • headless-web-sdk/ — Headless Web SDK docs only: @suki-sdk/platform-react, ambient hooks, and related API reference on this site. Hook guides live under headless-web-sdk/guides/hooks/ (auth-hook, ambient-hook, ambient-session-hook); other guides stay in guides/. (docs.json: Guides include a Hooks subgroup; API Reference lists platform-client first, then nested Types.) Do not document Dictation SDK packages, DictationClient, or iframe dictation here.
  • dictation-sdk/ — Dictation SDK docs only: @suki-sdk/core, @suki-sdk/dictation / dictation-react, SukiAuthManager, DictationClient, hosted iframe (In SDKs, the menu lists Dictation SDK (React) and Dictation SDK (JavaScript): each path starts with dictation-sdk/tracks/react or dictation-sdk/tracks/javascript (sidebar context), then shared pages (Introduction, Quickstart, Prerequisites, Installation, Changelog) and stack-specific integration guides under dictation-sdk/guides/; spec: dictation-sdk/Suki Dictation SDK.md). Do not blend Headless quickstarts or PlatformClient flows into these pages except a short “use Headless/Web SDK instead” pointer where the product comparison belongs. Page title Beta: scripts/wide-content.js injects the orange Beta pill on Headless Web SDK Overview and Dictation SDK Overview (path prefixes headless-web-sdk/ and dictation-sdk/). PDF title row: dictation-sdk/introduction is in export-pdf.js EXCLUDED_EXACT so the Beta badge stays inline with the title.
  • sdk-overview/ — SDK overview
  • Glossary/ — Glossary
  • updates/ — Release notes and announcements
  • Root — Shared assets: logo/, og-image/, new-favicon.ico, scripts/, style.css (see scripts/README.md for PDF export limits and third-party MDX/Mermaid → PDF options)
  • scripts/announcement-banner.js: Optional announcement bar (first body child, in flow, scrolls away); keeps Mintlify #navbar fixed and sets its top from the banner’s viewport bottom until the bar is off-screen; clears transform when applying top so layout stays flush; sets data-suki-announcement and --suki-mint-chrome-bottom for #sidebar-content. CONFIG at the top controls copy and enabled. Client JS cannot read docs.json, so toggles are: edit CONFIG, or remove "/scripts/announcement-banner.js" from docs.json scripts to disable entirely. See scripts/README.md (Site announcement banner).
  • scripts/export-pdf.js: PDF control (icon + label) next to the page h1 (browser print or Save as PDF). Edit EXCLUDED_PREFIXES / EXCLUDED_EXACT in that file to hide the control. When the user uses this control (html.suki-printing-pdf), prep injects /logo/dark-light.svg at the top of #content-area and removes it on afterprint. Print/PDF is theme-agnostic: @media print always applies the same light-on-paper typography (prose, code, pre, callouts, links, strong/b) whether the site is in light or dark UI, so you do not maintain parallel html.dark print rules. Layout helpers (flatten grid/flex, sticky/fixed, z-index, overflow-hidden) still apply under #content-area for OpenAPI-style pages; transform: none is not applied inside svg so Mermaid diagrams print correctly. primeMermaidForPrint() (before PDF/print) nudges window.mermaid to render when possible. No PDF button on paths in EXCLUDED_PREFIXES / EXCLUDED_EXACT: OpenAPI endpoint sections only (api-reference/authentication, ambient-sessions, audio-transcription, ambient-content, user-preferences, feedback, asynchronous, info), plus doc home/overview/introduction, SDK overview, updates/release-notes, updates/announcements, updates/release-notes-rss-feed. PDF is enabled on monthly pages updates/mmmYYYY-release-notes. For print/PDF, the script also opens all <details> (Mintlify Accordion) under #content-area, uses matchMedia('print'), double requestAnimationFrame before print(), plus beforeprint/afterprint cleanup. Tab panels are expanded the same way. Print layout rules are in style.css under @media print. release-notes-print.css (imported from style.css) plus scripts/release-notes-print-scope.js add html.suki-print-monthly-release-notes and extra print styling only on those monthly release note URLs. Do not add extra text-decoration: underline on links in print: Mintlify .link already uses a bottom border, which would double with underline in PDF.

Content Guidelines

  • Headless Web SDK vs Dictation SDK: Treat them as separate products. Keep headless-web-sdk/ pages scoped to ambient React hooks and @suki-sdk/platform-react. Keep dictation-sdk/ scoped to iframe dictation and Dictation packages. Allowed overlap: hub or decision pages (documentation/overview, integration-decision-guide, sdk-overview/overview, learning-path) where each product has its own section or tab; dictation-sdk/introduction may contrast with Web or Headless in one paragraph to steer readers. Do not copy Dictation install or API steps into Headless guides (or the reverse).
  • Use MDX for all documentation files
  • Mermaid: Use ```mermaid actions={false} (same line) on new diagrams so Mintlify does not render zoom/pan chrome that breaks browser PDF/print. If you need on-page controls for a specific diagram, set actions={true} and accept print noise, or add a static image for the PDF use case.
  • Include frontmatter with title and description
  • Images: use light/dark variants with className="block dark:hidden" and className="hidden dark:block" where appropriate
  • Follow healthcare/medical terminology standards; keep a professional, clinical tone for healthcare developers
  • Writing style: Follow the Writing style guide for voice, punctuation, capitalization, inclusivity, and terminology. Summary: no em dashes (use commas or colons); sentence-style capitalization for headings; Oxford comma; concise, scannable prose
  • Tabs: Home, Docs, SDKs, APIs, Glossary, Release Notes (defined in docs.json under navigation.tabs)
  • Docs tab: Getting Started, Onboarding & Authentication, Product Capabilities, Guides, Support/FAQs
  • SDKs tab: The SDKs tab uses Mintlify’s built-in menu on the tab (see Mintlify navigation – Menus): SDK overview, Web SDK, Mobile SDK, Headless Web SDK, and Dictation SDK, each with its own groups / pages tree. scripts/sdk-tab-menu-beta-badges.js adds Beta next to Headless Web SDK and Dictation SDK in that dropdown (see style.css). No custom script for the tab chevron or flyout chrome.
  • APIs tab: API Overview, API References (Authentication, Ambient Session Management, Dictation, Ambient Content, etc.)
  • Update docs.json when adding new pages; use flat paths (e.g. documentation/my-page, web-sdk/guides/ambient)

Web SDK

  • Use the existing code block structure with js and react tabs and code blocks with appropriate icons
  • Ensure code examples are clear and relevant to SDK usage
  • Add references and “read more” links to other sections of the documentation where helpful

Release Notes

  • When adding a new release section in updates/release-notes.mdx, add the LATEST badge to the newest release card only
  • Remove the LATEST badge from the previous release card
  • Only one release should have the LATEST badge at any time
  • Release notes RSS (hub): The hub page uses mode: frame; Mintlify does not emit <Update> items in RSS for frame pages. The combined feed lives on updates/release-notes-rss-feed.mdx (rss: true, hidden: true, no frame). Feed URL: /updates/release-notes-rss-feed/rss.xml. The RSS button on the hub links to that XML URL for subscription and feed readers. The Markdown source page /updates/release-notes-rss-feed stays available for editors (hidden from the sidebar). When you add a month to the timeline, add a matching <Update> in release-notes-rss-feed.mdx (newest first). See scripts/release-notes-rss.md.

Release Note Page Format

Release note pages live in updates/ and are named {month}{year}-release-notes.mdx (e.g. mar2026-release-notes.mdx). Page structure:
  1. Frontmatter: title (e.g. “March 2026”), description, sidebarTitle, rss: true
  2. Lead paragraph: One short summary of the release (no heading)
  3. Sections: Use ## What's New, ## What's Enhanced, ## What's Changed, ## What's Removed as needed
  4. Anchors: Add <span id="kebab-case-anchor" /> before each <Update> so deep links work
  5. Update blocks: Wrap each change in <Update label="..." description="..." tags={[...]}></Update>. Use tag="LATEST" only on the single newest update.
Per-item format (inside each <Update>):
  • Section heading: ### New Features | ### Enhancements | ### Deprecated | ### Removed (match the section)
  • Badge: <Badge size="sm" color="...">Product Version</Badge>
    • API: color="blue" (e.g. API v1.2.1)
    • Web SDK: color="green" (e.g. Web SDK 2.1.2)
    • Headless Web SDK: color="orange"
  • Bold title: One line summarizing the change (e.g. Audio streaming and download:)
  • Body: Short paragraph(s) describing what changed and how to use it
  • Why it matters: One line starting with Why it matters: explaining the benefit
  • Link: Learn more in the [Link text](path) documentation. or ... guide. (use relative path from updates/)
Badge colors: blue = API, green = Web SDK, orange = Headless Web SDK. Use consistent product names and version numbers. Style: Follow the Writing style guide. No em dashes; use commas or colons. Professional, developer-focused tone. Link to the relevant doc or API reference for details.
Last modified on April 20, 2026