> ## Documentation Index
> Fetch the complete documentation index at: https://tomee-mintlify-fd4daece.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Generate SDK reference pages from doc-tool output

> Publish SDK reference documentation in Mintlify from TypeDoc, DocFX, Javadoc, Sphinx, or phpDocumentor artifacts using the sdk navigation property.

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

| `format`  | Tool                                                                             | Artifact                                                  |
| --------- | -------------------------------------------------------------------------------- | --------------------------------------------------------- |
| `typedoc` | [TypeDoc](https://typedoc.org) (TypeScript/JavaScript)                           | JSON export file                                          |
| `docfx`   | [DocFX](https://dotnet.github.io/docfx/) (.NET)                                  | `docfx metadata` output directory (ManagedReference YAML) |
| `javadoc` | [Javadoc](https://docs.oracle.com/en/java/javase/17/javadoc/javadoc.html) (Java) | Standard doclet HTML directory                            |
| `sphinx`  | [Sphinx](https://www.sphinx-doc.org) (Python)                                    | JSON builder output directory                             |
| `phpdoc`  | [phpDocumentor](https://phpdoc.org) (PHP)                                        | `structure.xml` file                                      |

## 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.

<CodeGroup>
  ```bash TypeDoc theme={null}
  npx typedoc --json typedoc.json src/index.ts
  ```

  ```bash DocFX theme={null}
  docfx metadata docfx.json
  ```

  ```bash Javadoc theme={null}
  javadoc -d javadoc-output -sourcepath src/main/java -subpackages com.example
  # Or download the published javadoc jar from Maven Central
  ```

  ```bash Sphinx theme={null}
  python -m sphinx -b json docs/source artifacts/json
  ```

  ```bash phpDocumentor theme={null}
  phpdoc -d src -t artifacts --template=xml
  ```
</CodeGroup>

## 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.

```json theme={null}
"navigation": {
  "tabs": [
    {
      "tab": "SDK Reference",
      "sdk": {
        "format": "typedoc",
        "source": "sdk-artifacts/typedoc.json",
        "directory": "sdk/typescript"
      }
    }
  ]
}
```

<Note>
  You must declare `sdk` on a [tab](/organize/navigation#tabs). 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.
</Note>

<ParamField path="format" type="string" required>
  The documentation tool that produced the artifact: `typedoc`, `docfx`, `javadoc`, `sphinx`, or `phpdoc`.
</ParamField>

<ParamField path="source" type="string" required>
  Relative path to the artifact file or directory in your docs repository, or an HTTPS URL. Does not accept HTTP URLs.
</ParamField>

<ParamField path="directory" type="string">
  The URL path prefix for generated pages. Defaults to `sdk-reference`.
</ParamField>

Add multiple tabs to document multiple libraries. Use a unique `directory` for each library to avoid route collisions.

<Tip>
  Add your artifact directory to [`.mintignore`](/organize/mintignore) so Mintlify treats artifacts as build inputs rather than publishing them as static assets.
</Tip>

## 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:

```json theme={null}
{
  "tab": "Java SDK",
  "sdk": {
    "format": "javadoc",
    "source": "https://repo1.maven.org/maven2/com/example/my-library/1.0.0/my-library-1.0.0-javadoc.jar",
    "directory": "sdk/java"
  }
}
```

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.

## Where do the docs and code live?

Your SDK code does not need to live in the same repository as your docs. Pick the pattern that matches your setup.

### SDK and docs in the same repository

The simplest setup. Generate the artifact in the same repository as your docs 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 the next docs deployment picks it up automatically.

This works for a monorepo that contains both the SDK source and the docs.

### SDK in a separate repository

When the SDK lives in its own repository, you have two options.

1. **Commit the artifact to your docs 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 docs repository with the updated file. Merging that change to your deployment branch triggers a docs deployment on its own, so no extra API call is needed. 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) and set `source` to that URL. Because nothing changes in your docs repository when the SDK updates, you also need to trigger a docs deployment so the new artifact is fetched. Call the [Trigger deployment](/api/update/trigger) endpoint from your SDK release pipeline after the artifact is published. See [Remote artifact limits](#use-remote-sources) for size constraints.

<Tip>
  Prefer committing the artifact when your SDK release cadence is low or you want the docs repository to be the source of truth. Prefer hosting the artifact when releases are frequent, artifacts are large, or you already publish them (for example, Javadoc jars on Maven Central).
</Tip>