Skip to main content

Integration

OpenAPI integration

Auto-generated API reference pages from your openapi.json or openapi.yaml — push the spec, get a docs site.

How it works

Drop an OpenAPI 2.0 / 3.0 / 3.1 spec into your repo, point nookdocs.config.json at it, and NookDocs auto-generates a full API reference for every endpoint. No template writing, no MDX per endpoint — the spec is the source of truth.

Add your spec to the repo

Commit openapi.json (or any path you prefer) alongside your existing docs files. The api.openapi path is relative to your docs base.

Point config at it

Add the api.openapi field in nookdocs.config.json:

{
  "name": "Acme API",
  "api": {
    "openapi": "openapi.json",
    "playground": true
  },
  "navigation": [...]
}

Push to GitHub

The sync job fetches the spec, parses it via swagger-parser (full $ref resolution), and stores the parsed endpoints in the database.

Endpoint pages live

Every operation is reachable at /api-reference/{tag}/{operation-id}. The platform renders the full page using the existing <ApiMethod>, <ParamField>, <ResponseField>, and <Expandable> components.

URL pattern

Each endpoint becomes a page at:

/api-reference/{tag}/{operation-id}

The tag comes from the operation's tags[0] field (or default if none). The operation-id is the spec's operationId field (or a generated fallback like get-users-id if missing). Tags with spaces are slugified — "User Management" becomes user-management in the URL.

What's auto-generated

For every operation, the rendered page includes:

Method + URL

Color-coded <ApiMethod> badge next to the path

Description

Operation summary as the page h1, full description as the lead paragraph

Authorization

Security requirements section if the operation has any

Path parameters

<ParamField path="path"> per parameter, with type, required, and description

Query parameters

<ParamField path="query"> with default values and enum options surfaced

Headers

Required headers as <ParamField path="header">

Request body

Top-level body properties as <ParamField path="body">. Nested objects expand via <Expandable>.

Responses

One section per status code with the response schema as <ResponseField> entries

Supported spec versions

VersionSupport
OpenAPI 3.1✅ Full
OpenAPI 3.0✅ Full
Swagger 2.0✅ Full (body params auto-promoted to requestBody)

The parser uses @apidevtools/swagger-parser under the hood, which validates the spec and dereferences every $ref before we touch it. Invalid specs surface in your build log so you can fix them on the next push.

Schema features

FeatureSupport
$ref (local references)✅ Inlined at parse time
oneOf, anyOf, allOf✅ Stored, renderer flattening in Phase 4 follow-up
Nested object schemas✅ One level via <Expandable>
Enum values✅ Surfaced as inline pills under the param
Default values✅ Shown in the param metadata row
Deprecated flag✅ Strikethrough + warning badge
File uploads (multipart/form-data)⏳ Planned
Webhooks (3.1)⏳ Planned
Callbacks⏳ Planned

Mixing manual MDX with auto-generated pages

The auto-generation only kicks in when there's no MDX page at the requested path. So you can override any auto-generated page by writing a manual MDX file at the same URL:

docs/api-reference/users/get-user.mdx

This wins over the auto-generated /api-reference/users/get-user. Use it when you want to add prose explanations, custom code examples, or migration notes that the spec alone can't express.

The recommended pattern: let auto-generation handle the bulk of your endpoints, write manual MDX only for the 5-10% that need extra context.

YAML and JSON

Both formats work. Point api.openapi at a .json, .yaml, or .yml spec and NookDocs parses it either way — YAML is a JSON superset, so you can keep your spec in whichever format your API framework emits (FastAPI, NestJS, Spring Boot, and most others emit either). No conversion step.

Configure once, deploy forever

After your first push with api.openapi configured, the sync job auto-runs on every subsequent push. Update your spec, commit, push — the API reference updates 30 seconds later. No manual rebuild step.

Try it

If you have a working OpenAPI spec, drop it at your docs base (relative to the base), add "api": { "openapi": "openapi.json" } to your nookdocs.config.json, and push. You'll have a fully-rendered API reference at /api-reference/{tag}/{operation-id} for every endpoint in your spec.

What's next

PhaseAddition
4.3Try-it playground modal — click "Try it" on any endpoint, fill the form, fire a real request from the browser
4.4Versioning — versions: ["v1", "v2"] config + version selector in the navbar
4.5Custom domain DNS verification (separate feature, lands in the same phase)
4 follow-upYAML spec support + Phase 4 follow-up: oneOf/anyOf rendering, file upload params
Was this page helpful?

Last updated August 13, 2026