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
| Version | Support |
| 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
| Feature | Support |
$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.mdxThis 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
| Phase | Addition |
| 4.3 | Try-it playground modal — click "Try it" on any endpoint, fill the form, fire a real request from the browser |
| 4.4 | Versioning — versions: ["v1", "v2"] config + version selector in the navbar |
| 4.5 | Custom domain DNS verification (separate feature, lands in the same phase) |
| 4 follow-up | YAML spec support + Phase 4 follow-up: oneOf/anyOf rendering, file upload params |