FastAPI generates a full OpenAPI 3.1 schema for you automatically, served at /openapi.json on every running app — there's no separate annotation step like Express or Django need. That means "generate an SDK from FastAPI" is really two much smaller problems: get the spec out clean, then run it through a generator or a hosted pipeline like Sourced that turns it into a TypeScript or Python SDK plus hosted docs in one pass.
Where FastAPI exposes its OpenAPI spec
By default, a running FastAPI app serves its schema at /openapi.json — no configuration needed. Two docs UIs read that same schema: Swagger UI at /docs and ReDoc at /redoc.
All three paths are configurable on the FastAPI() constructor:
from fastapi import FastAPI
app = FastAPI(
openapi_url="/api/v1/openapi.json", # move the spec
docs_url="/documentation", # move Swagger UI
redoc_url=None, # disable ReDoc
)
Setting openapi_url=None disables the schema (and both docs UIs) entirely — useful for an internal service you don't want introspectable, but obviously not what you want if the goal is a public SDK.
Metadata that shows up in the spec's info object — title, description, version, contact, license — is also set on the constructor:
app = FastAPI(
title="ChimichangApp",
description="ChimichangApp API helps you do awesome stuff. 🚀",
summary="Deadpool's favorite app. Nuff said.",
version="0.0.1",
contact={"name": "Deadpoolio the Amazing", "email": "dp@x-force.example.com"},
license_info={"name": "Apache 2.0", "identifier": "Apache-2.0"},
)
To pull the file for a generator, either hit the running server (curl localhost:8000/openapi.json -o openapi.json) or use FastAPI's own app.openapi() method in a small script if you'd rather generate it without booting the server.
Two FastAPI-specific gotchas that hurt SDK output
FastAPI's automatic schema generation is a strength, but it inherits two failure modes that matter more once you're generating a public SDK instead of just reading the spec yourself.
1. Auto-generated operationIds aren't stable method names
FastAPI does assign an operationId to every operation by default — it isn't blank. But unless you set one explicitly, or pass a generate_unique_id_function, the default is derived from internals rather than chosen by you:
@app.get("/items/", operation_id="some_specific_id_you_define")
async def read_items():
return [{"item_id": "Foo"}]
FastAPI's own docs are explicit about the risk of the alternative — using route function names as IDs: "you have to make sure each one of your path operation functions has a unique name, even if they are in different modules." Two routers with a get_item function each will collide. For SDK generation this is the same failure mode as a spec with no operationId at all: an unstable, generator-invented method name that changes when you refactor. See how to fix missing operationId errors for the naming convention that survives refactors, and set operation_id explicitly on any endpoint you expect customers to call by name.
2. Untyped responses become anonymous schemas
FastAPI turns a Pydantic model's class name into a named entry in components/schemas — that part works well. But a response typed as a bare dict, Any, or an un-modeled List[dict] has no class name to reuse, so the generated OpenAPI schema for that response has no name either. Generators facing that anonymous shape invent one, the same way they do for any other unnamed inline schema — see fixing inline schema names like Type1 and InlineObject for what that looks like downstream. The fix is the same one FastAPI's own docs recommend for response typing generally: give every endpoint an explicit response_model backed by a Pydantic class.
From FastAPI's spec to hosted docs and typed SDKs
Once /openapi.json is clean — real operationIds, real response models — turning it into something customers install is a separate step, and with docs and SDK previews together, it's the shortest path from OpenAPI spec to live docs and SDK previews. With Sourced:
- Point Sourced at your OpenAPI file or repo. Connect from GitHub and Sourced pulls the spec straight from your FastAPI service, or paste the
/openapi.jsonoutput directly. - Preview the generated SDKs. Sourced renders TypeScript and Python SDK previews — package structure, method names, typed errors — before anything is published, so a
read_item_items__item_id__get-style method name is visible in preview, not in a customer's IDE. - Get hosted docs and llms.txt in the same pass. The same spec produces a hosted docs preview site and an llms.txt file for agent-readable discovery, without a separate docs pipeline.
- Publish when it's clean. Free unlimited previews and up to 2 hosted noindex docs review sites and one hosted MCP server get you through steps 1-3 with no credit card.
Comparison: FastAPI's built-in tools vs. a full SDK pipeline
| Need | FastAPI gives you | What it doesn't give you |
|---|---|---|
| A readable OpenAPI spec | /openapi.json, out of the box |
Nothing — this part is genuinely free |
| Interactive API browsing | Swagger UI (/docs), ReDoc (/redoc) |
A docs site customers install SDKs from |
| A typed Python client | Nothing built in | Generated Python SDK, packaged and versioned |
| A typed TypeScript client for frontend/mobile consumers | Nothing built in | Generated TypeScript SDK |
Agent-readable docs (llms.txt) |
Nothing built in | An llms.txt derived from the same spec |
| A diff before you publish a breaking change | Nothing built in | A compatibility report against your last SDK version |
OSS generators for other languages
Sourced's generated SDKs focus on Python and TypeScript today — the two ecosystems where teams publish first, and where a FastAPI service's own backend and typical frontend consumers already live. If you need a target beyond those two, FastAPI's clean spec output works with the standard per-language OSS generators too — pick your target from Go, Java, Ruby, PHP, C#, Kotlin, Rust, or Swift and run OpenAPI Generator locally against the same /openapi.json. The five-minute generate-an-SDK walkthrough covers the generic local-generator path if you want to try that first.
Honest scope: when the FastAPI defaults are enough
If your API has a handful of internal consumers who already read Python, httpx against /openapi.json-documented endpoints plus Swagger UI for reference is genuinely fine — don't add a codegen pipeline you don't need. If your only consumers are other FastAPI/Python services on your own team, FastAPI's own TestClient-adjacent patterns and a thin shared httpx.Client wrapper cost less than standing up SDK generation. Reach for a real SDK pipeline once you have external customers, multiple languages, or a docs site to maintain — that's the point where hand-maintained clients start silently drifting from the spec.
FAQ
Does FastAPI generate an SDK for me automatically?
No. FastAPI generates the OpenAPI spec automatically at /openapi.json — it does not generate a client SDK. You still need a generator (local, like OpenAPI Generator, or hosted, like Sourced) to turn that spec into an installable package.
What's the default OpenAPI spec URL in FastAPI?
/openapi.json, relative to your app's root. It's configurable via the openapi_url parameter on the FastAPI() constructor, and can be disabled entirely by setting openapi_url=None.
Does FastAPI support OpenAPI 3.1?
Yes, current FastAPI versions emit OpenAPI 3.1 by default. If your SDK generator or docs tool is 3.0-only, see OpenAPI 3.1 vs 3.0 for how to downgrade safely.
Why does my generated SDK have ugly method names like read_item_items__item_id__get?
That's FastAPI's fallback operationId shape when you haven't set one explicitly. Set operation_id per route, or pass a generate_unique_id_function to FastAPI() with a naming scheme you control — see fixing missing operationId errors for the pattern.
Can I generate the OpenAPI spec without running the server?
Yes. Call app.openapi() in a small script after importing your FastAPI app instance and write the returned dict to a file — no need to boot a live server just to extract the schema.
Do I need Pydantic response models to get a good SDK?
Effectively yes. A response_model backed by a Pydantic class gives every response a named, reusable schema. Skipping it (returning bare dict or Any) produces an anonymous inline schema that generators name for you — usually badly.
Ship it
FastAPI already did the hard part — a real, versioned OpenAPI spec, for free, on every request to /openapi.json. Start free on Sourced and turn that spec into hosted docs, a TypeScript SDK preview, and a Python SDK preview in one pass, or run your file through the OpenAPI validator first to catch the operationId and response-model gaps before you generate anything.