How-to

Generate an OpenAPI spec from your existing code.

If you have a working API but no OpenAPI spec, the fastest path is usually to generate one from the framework you already use. This page is a short guide to the tools per language and what to do with the resulting spec.

Completely free for 30 days. No credit card required.

  • InputOpenAPI spec
  • LanguagesTS + Python
  • DocsPreview + llms.txt
  • ReleaseLaunch checks

01Details

Per-language options

01

TypeScript / NestJS: @nestjs/swagger ships an OpenAPI generator that reads decorators on controllers and DTOs.

02

TypeScript / Fastify: @fastify/swagger derives a spec from JSON Schema route options.

03

Python / FastAPI: built-in OpenAPI generator from type hints and Pydantic models — the cleanest in the ecosystem.

04

Python / Django REST: drf-spectacular generates from serializers and viewsets.

05

Go: swaggo/swag or go-swagger (annotations on handlers).

06

Java / Spring: springdoc-openapi reads annotations and @RestController mappings.

02Details

What you'll need to do by hand

01

Add operation IDs (most generators pick weak defaults).

02

Provide examples for request bodies and responses.

03

Tag operations into resource groups so generated SDKs nest correctly.

04

Pull duplicate schemas into components.schemas so generated types aren't _1/_2 variants.

03Outputs

What to do with the generated spec

01

Validate it (Spectral, Stoplight, openapi-cli).

02

Generate SDKs from it (Bloom emits TypeScript + Python from the same spec).

03

Host docs from it (custom domain, redirects, llms.txt).

04

Use the spec as the contract for contract tests against the running service.

04Details

Why this matters for the SDK side

01

A spec generated from code is automatically in sync with the running service.

02

Once the spec exists, SDK regeneration is a one-command step.

03

The compatibility report (Bloom) tells you if any SDK change would break customers.