FastAPI

Official FastAPI skill to write code with best practices, keeping up to date with new versions and features.

Use the

fastapi

CLI

Run the development server on localhost with reload:

fastapi dev

Run the production server:

fastapi run

Add an entrypoint in

pyproject.toml

FastAPI CLI will read the entrypoint in

pyproject.toml

to know where the FastAPI app is declared.

[tool.fastapi]
entrypoint = "my_app.main:app"

Use

fastapi

with a path

When adding the entrypoint to

pyproject.toml

is not possible, or the user explicitly asks not to, or it's running an independent small app, you can pass the app file path to the

fastapi

command:

fastapi dev my_app/main.py

Prefer to set the entrypoint in

pyproject.toml

when possible.

Use

Annotated

Always prefer the

Annotated

style for parameter and dependency declarations.

It keeps the function signatures working in other contexts, respects the types, allows reusability.

In Parameter Declarations

Use

Annotated

for parameter declarations, including

Path

,

Query

,

Header

, etc.:

from typing import Annotated

from fastapi import FastAPI, Path, Query

app = FastAPI()


@app.get("/items/{item_id}")
async def read_item(
    item_id: Annotated[int, Path(ge=1, description="The item ID")],
    q: Annotated[str | None, Query(max_length=50)] = None,
):
    return {"message": "Hello World"}

instead of:

# DO NOT DO THIS
@app.get("/items/{item_id}")
async def read_item(
    item_id: int = Path(ge=1, description="The item ID"),
    q: str | None = Query(default=None, max_length=50),
):
    return {"message": "Hello World"}

For Dependencies

Use

Annotated

for dependencies with

Depends()

.

Unless asked not to, create a new type alias for the dependency to allow re-using it.

from typing import Annotated

from fastapi import Depends, FastAPI

app = FastAPI()


def get_current_user():
    return {"username": "johndoe"}


CurrentUserDep = Annotated[dict, Depends(get_current_user)]


@app.get("/items/")
async def read_item(current_user: CurrentUserDep):
    return {"message": "Hello World"}

instead of:

# DO NOT DO THIS
@app.get("/items/")
async def read_item(current_user: dict = Depends(get_current_user)):
    return {"message": "Hello World"}

Do not use Ellipsis for path operations or Pydantic models

Do not use

...

as a default value for required parameters, it's not needed and not recommended.

Do this, without Ellipsis (

...

):

from typing import Annotated

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


class Item(BaseModel):
    name: str
    description: str | None = None
    price: float = Field(gt=0)


app = FastAPI()


@app.post("/items/")
async def create_item(item: Item, project_id: Annotated[int, Query()]): ...

instead of this:

# DO NOT DO THIS
class Item(BaseModel):
    name: str = ...
    description: str | None = None
    price: float = Field(..., gt=0)


app = FastAPI()


@app.post("/items/")
async def create_item(item: Item, project_id: Annotated[int, Query(...)]): ...

Return Type or Response Model

When possible, include a return type. It will be used to validate, filter, document, and serialize the response.

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()


class Item(BaseModel):
    name: str
    description: str | None = None


@app.get("/items/me")
async def get_item() -> Item:
    return Item(name="Plumbus", description="All-purpose home device")

Important: Return types or response models are what filter data ensuring no sensitive information is exposed. And they are used to serialize data with Pydantic (in Rust), this is the main idea that can increase response performance.

The return type doesn't have to be a Pydantic model, it could be a different type, like a list of integers, or a dict, etc.

When to use

response_model

instead

If the return type is not the same as the type that you want to use to validate, filter, or serialize, use the

response_model

parameter on the decorator instead.

from typing import Any

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()


class Item(BaseModel):
    name: str
    description: str | None = None


@app.get("/items/me", response_model=Item)
async def get_item() -> Any:
    return {"name": "Foo", "description": "A very nice Item"}

This can be particularly useful when filtering data to expose only the public fields and avoid exposing sensitive information.

from typing import Any

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()


class InternalItem(BaseModel):
    name: str
    description: str | None = None
    secret_key: str


class Item(BaseModel):
    name: str
    description: str | None = None


@app.get("/items/me", response_model=Item)
async def get_item() -> Any:
    item = InternalItem(
        name="Foo", description="A very nice Item", secret_key="supersecret"
    )
    return item

Performance

Do not use

ORJSONResponse

or

UJSONResponse

, they are deprecated.

Instead, declare a return type or response model. Pydantic will handle the data serialization on the Rust side.

Including Routers

When declaring routers, prefer to add router level parameters like prefix, tags, etc. to the router itself, instead of in

include_router()

.

Do this:

from fastapi import APIRouter, FastAPI

app = FastAPI()

router = APIRouter(prefix="/items", tags=["items"])


@router.get("/")
async def list_items():
    return []


# In main.py
app.include_router(router)

instead of this:

# DO NOT DO THIS
from fastapi import APIRouter, FastAPI

app = FastAPI()

router = APIRouter()


@router.get("/")
async def list_items():
    return []


# In main.py
app.include_router(router, prefix="/items", tags=["items"])

There could be exceptions, but try to follow this convention.

Apply shared dependencies at the router level via

dependencies=[Depends(...)]

.

Dependency Injection

Use dependencies when:

• They can't be declared in Pydantic validation and require additional logic
• The logic depends on external resources or could block in any other way
• Other dependencies need their results (it's a sub-dependency)
• The logic can be shared by multiple endpoints to do things like error early, authentication, etc.
• They need to handle cleanup (e.g., DB sessions, file handles), using dependencies with

  yield

• Their logic needs input data from the request, like headers, query parameters, etc.

Dependencies with

yield

and

scope

When using dependencies with

yield

, they can have a

scope

that defines when the exit code is run.

Use the default scope

"request"

to run the exit code after the response is sent back.

from typing import Annotated

from fastapi import Depends, FastAPI

app = FastAPI()


def get_db():
    db = DBSession()
    try:
        yield db
    finally:
        db.close()


DBDep = Annotated[DBSession, Depends(get_db)]


@app.get("/items/")
async def read_items(db: DBDep):
    return db.query(Item).all()

Use the scope

"function"

when they should run the exit code after the response data is generated but before the response is sent back to the client.

from typing import Annotated

from fastapi import Depends, FastAPI

app = FastAPI()


def get_username():
    try:
        yield "Rick"
    finally:
        print("Cleanup up before response is sent")

UserNameDep = Annotated[str, Depends(get_username, scope="function")]

@app.get("/users/me")
def get_user_me(username: UserNameDep):
    return username

Class Dependencies

Avoid creating class dependencies when possible.

If a class is needed, instead create a regular function dependency that returns a class instance.

Do this:

from dataclasses import dataclass
from typing import Annotated

from fastapi import Depends, FastAPI

app = FastAPI()


@dataclass
class DatabasePaginator:
    offset: int = 0
    limit: int = 100
    q: str | None = None

    def get_page(self) -> dict:
        # Simulate a page of data
        return {
            "offset": self.offset,
            "limit": self.limit,
            "q": self.q,
            "items": [],
        }


def get_db_paginator(
    offset: int = 0, limit: int = 100, q: str | None = None
) -> DatabasePaginator:
    return DatabasePaginator(offset=offset, limit=limit, q=q)


PaginatorDep = Annotated[DatabasePaginator, Depends(get_db_paginator)]


@app.get("/items/")
async def read_items(paginator: PaginatorDep):
    return paginator.get_page()

instead of this:

# DO NOT DO THIS
from typing import Annotated

from fastapi import Depends, FastAPI

app = FastAPI()


class DatabasePaginator:
    def __init__(self, offset: int = 0, limit: int = 100, q: str | None = None):
        self.offset = offset
        self.limit = limit
        self.q = q

    def get_page(self) -> dict:
        # Simulate a page of data
        return {
            "offset": self.offset,
            "limit": self.limit,
            "q": self.q,
            "items": [],
        }


@app.get("/items/")
async def read_items(paginator: Annotated[DatabasePaginator, Depends()]):
    return paginator.get_page()

Async vs Sync path operations

Use

async

path operations only when fully certain that the logic called inside is compatible with async and await (it's called with

await

) or that doesn't block.

from fastapi import FastAPI

app = FastAPI()


# Use async def when calling async code
@app.get("/async-items/")
async def read_async_items():
    data = await some_async_library.fetch_items()
    return data


# Use plain def when calling blocking/sync code or when in doubt
@app.get("/items/")
def read_items():
    data = some_blocking_library.fetch_items()
    return data

In case of doubt, or by default, use regular

def

functions, those will be run in a threadpool so they don't block the event loop.

The same rules apply to dependencies.

Make sure blocking code is not run inside of

async

functions. The logic will work, but will damage the performance heavily.

Asyncer

When needing to run blocking code inside of async functions, or async code inside of blocking functions, suggest using Asyncer.

Install:

uv add asyncer

Run blocking sync code inside of async with

asyncify()

:

from asyncer import asyncify
from fastapi import FastAPI

app = FastAPI()


def do_blocking_work(name: str) -> str:
    # Some blocking I/O operation
    return f"Hello {name}"


@app.get("/items/")
async def read_items():
    result = await asyncify(do_blocking_work)(name="World")
    return {"message": result}

And run async code inside of blocking sync code with

syncify()

:

from asyncer import syncify
from fastapi import FastAPI

app = FastAPI()


async def do_async_work(name: str) -> str:
    return f"Hello {name}"


@app.get("/items/")
def read_items():
    result = syncify(do_async_work)(name="World")
    return {"message": result}

Use uv, ruff, ty

If uv is available, use it to manage dependencies.

If Ruff is available, use it to lint and format the code. Consider enabling the FastAPI rules.

If ty is available, use it to check types.

SQLModel for SQL databases

When working with SQL databases, prefer using SQLModel as it is integrated with Pydantic and will allow declaring data validation with the same models.

Do not use Pydantic RootModels

Do not use Pydantic

RootModel

, instead use regular type annotations with

Annotated

and Pydantic validation utilities.

For example, for a list with validations you could do:

from typing import Annotated

from fastapi import Body, FastAPI
from pydantic import Field

app = FastAPI()


@app.post("/items/")
async def create_items(items: Annotated[list[int], Field(min_length=1), Body()]):
    return items

instead of:

# DO NOT DO THIS
from typing import Annotated

from fastapi import FastAPI
from pydantic import Field, RootModel

app = FastAPI()


class ItemList(RootModel[Annotated[list[int], Field(min_length=1)]]):
    pass


@app.post("/items/")
async def create_items(items: ItemList):
    return items

FastAPI supports these type annotations and will create a Pydantic

TypeAdapter

for them, so that types can work as normally and there's no need for the custom logic and types in RootModels.

Use one HTTP operation per function

Don't mix HTTP operations in a single function, having one function per HTTP operation helps separate concerns and organize the code.

Do this:

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()


class Item(BaseModel):
    name: str


@app.get("/items/")
async def list_items():
    return []


@app.post("/items/")
async def create_item(item: Item):
    return item

instead of this:

# DO NOT DO THIS
from fastapi import FastAPI, Request
from pydantic import BaseModel

app = FastAPI()


class Item(BaseModel):
    name: str


@app.api_route("/items/", methods=["GET", "POST"])
async def handle_items(request: Request):
    if request.method == "GET":
        return []