Skip to main content
Use the sdk navigation property to generate reference pages for your SDK libraries from the documentation tools you already run. Mintlify reads each tool’s build artifact and creates a page for every class, interface, module, and function, with navigation groups, cross-page links, and search indexing included.

​
Supported formats

​
Generate an artifact

Run your documentation tool with a machine-readable output format. If you already publish generated docs from CI, this is usually a one-flag change to the same command.

​
Auto-populate SDK pages

Add an sdk property to a tab in your docs.json. Mintlify parses the artifact and creates navigation groups and pages for the library.
You must declare sdk on a tab. A tab with sdk may include groups, but no other navigation structures, such as pages, versions, or languages. It also cannot include an openapi, asyncapi, or graphql property.
​
string
required
The documentation tool that produced the artifact: typedoc, docfx, javadoc, sphinx, or phpdoc.
​
string
required
Relative path to the artifact file or directory in your docs repository, or an HTTPS URL. Does not accept HTTP URLs.
​
string
The URL path prefix for generated pages. Defaults to sdk-reference.
Add multiple tabs to document multiple libraries. Use a unique directory for each library to avoid route collisions.
Add your artifact directory to .mintignore so Mintlify treats artifacts as build inputs rather than publishing them as static assets.

​
Generated pages

Mintlify adds the generated navigation groups after any groups on the tab. The groups vary by format and may represent modules, packages, namespaces, or symbol types. Each generated page documents a class, interface, function, type, or other symbol from the artifact and links to related generated pages. If a converter produces pages that do not belong to a group, Mintlify collects them under a Reference group.

​
Use remote sources

Set source to an HTTPS URL to fetch the artifact at build time instead of committing it to your docs repository. Single-file formats (typedoc, phpdoc) accept a direct file URL. Directory formats (docfx, javadoc, sphinx) accept a zip archive. Javadoc jars published to Maven Central work without repackaging:
Remote artifacts have a 50 MB download limit and a 200 MB extracted size limit.

​
Keep references up to date

Regenerate the artifact whenever your SDK changes. A common pattern is a CI job in each SDK repository that runs the documentation tool on release. The job either commits the artifact to your docs repository or uploads it to a stable URL that source points to.

​
Repository setup

Store your SDK code and documentation in the same repository or separate repositories. Pick the pattern that matches your setup. Both options support the same capabilities.

​
SDK and documentation in the same repository

Generate your SDK artifact in the same repository as your documentation and point source at its relative path. Any workflow that already produces the artifact on push or release can commit it back to the repository, and publish updates as part of the next documentation site deployment.

​
SDK in a separate repository

When the SDK is in its own repository, you have two options.
  1. Commit the artifact to your documentation repository. In the SDK repository, run a CI job on release that generates the artifact and opens a pull request (or pushes a commit) to your documentation repository with the updated file. Merge that change to your deployment branch to trigger a site deployment. Point source at the committed path, the same as the single-repository setup.
  2. Host the artifact and fetch it at build time. Upload the artifact to a stable HTTPS URL. For example, an S3 bucket, GitHub Releases asset, or Maven Central for Javadoc jars. Set source to the URL. Trigger a documentation site deployment to fetch the new artifact whenever you update it. Call the Trigger deployment endpoint from your SDK release pipeline after you publish the artifact.
If your release cadence is low or you want the documentation repository to be the source of truth, commit the artifact to your documentation repository. If your releases are frequent, artifacts are large, or you already publish them (for example, Javadoc jars on Maven Central), host the artifact and fetch it at build time.