Automatic docs: /docs and /redoc

Documentation you didn't write

Every FastAPI app automatically serves two documentation pages, generated entirely from what you’ve already written — no separate documentation effort, no extra annotations beyond what’s already in your route signatures and Pydantic models:

/docs — an interactive UI (Swagger UI) listing every route, grouped and expandable, with a “Try it out” button that sends a real request from the browser and shows the actual response.
/redoc — a cleaner, read-only reference view (ReDoc) of the same information, better suited to sharing as reference documentation than to interactively poking at.

Both are generated from the exact same source: an OpenAPI schema FastAPI builds automatically by inspecting your routes, their parameters, and their Pydantic models — visiting /openapi.json on any FastAPI app shows that schema directly, as raw JSON.

What ends up in the docs, and where it comes from

Nothing here is new information — it’s everything from this lesson so far, surfaced automatically:

from fastapi import FastAPI, Query
from pydantic import BaseModel, Field

app = FastAPI()

class AgentConfig(BaseModel):
    name: str = Field(description="the agent's unique identifier")
    model: str = Field(description="which LLM this agent runs on")
    temperature: float = Field(default=0.7, description="sampling temperature, 0 to 1")

@app.post("/agents", response_model=AgentConfig, status_code=201)
def create_agent(config: AgentConfig):
    """Register a new agent configuration."""
    return config

@app.get("/agents")
def list_agents(limit: int = Query(default=10, gt=0, le=100, description="max results to return")):
    """List existing agents, most recently created first."""
    return []

This is what visiting /docs for that app actually looks like — interactive, with a (non-functional here) “Try it out” per route:

/docs · Swagger UI (illustrative)

POST/agentsCreate Agent

Request body

Field	Type	Description
`name`required	string	the agent's unique identifier
`model`required	string	which LLM this agent runs on
`temperature`	number	sampling temperature, 0 to 1 (default 0.7)

GET/agentsList Agents

List existing agents, most recently created first.

Parameters

Field	Type	Description
`limit`	integer	max results to return (default 10, 1-100)

/redoc shows the same underlying schema, laid out as a cleaner reference page instead of an interactive one:

/redoc · ReDoc (illustrative)

POST/agents

Create Agent

Request body schema

Field	Type	Description
`name`required	string	the agent's unique identifier
`model`required	string	which LLM this agent runs on
`temperature`	number	sampling temperature, 0 to 1 (default 0.7)

GET/agents

List Agents

List existing agents, most recently created first.

Parameters

Field	Type	Description
`limit`	integer	max results to return (default 10, 1-100)

And underneath both of those is the same raw OpenAPI schema:

The schema behind the docs

click Run to see this pane's output

Visiting /docs for this app shows: both routes, each with its docstring — exactly the same docstring mechanism from the functions lesson, now read by FastAPI’s docs generator instead of an LLM tool-calling framework, though it’s worth noticing these are genuinely the same underlying idea — as its description; create_agent’s expected request body shown field-by-field, each with its Field(description=...) text and whether it’s required; list_agents’s limit parameter shown as optional, with its range constraint and description visible directly, exactly as the schema excerpt above shows.

Why this matters more than "nice to have"

This isn’t just convenient for humans browsing the API — it’s the same throughline as why type hints and docstrings mattered for tool-calling frameworks back in the functions lesson: a machine-readable OpenAPI schema, generated the same automatic way, is exactly the kind of structured description an LLM-based tool-calling system can consume directly to know what an endpoint expects and returns — the same underlying description serving both a human reading /docs and, potentially, an agent deciding how to call your API as a tool.

Check your understanding

1/5

What generates the content shown at /docs and /redoc?