FastAPI Cheat Sheet

Table 1: Core Application Setup

Everything starts with the FastAPI() instance and the path-operation decorators that hang routes off it. These are the pieces you write in your very first file — creating the app, defining an endpoint, choosing sync or async, and wiring up startup logic with a lifespan handler. The automatic /docs and Pydantic integration listed here are also why FastAPI feels productive from line one.

Table 2: HTTP Methods and Route Definitions

Each HTTP method maps to a decorator and a conventional meaning — GET reads, POST creates, PUT replaces, PATCH partially updates, DELETE removes. Following these conventions keeps your API predictable and lets caches, browsers, and other tools behave correctly. The lesser-used HEAD and OPTIONS round out the set for existence checks and CORS handling.

Table 3: Request Parameters

Data reaches your endpoint from several places — the URL path, the query string, the JSON body, headers, cookies, form fields, and uploaded files — and FastAPI pulls each one in just by declaring it as a typed function argument. The standout feature is that the type annotation alone drives parsing and validation, so a path parameter declared as int is automatically rejected if someone passes text. Knowing which source maps to which declaration is the core skill this table builds.

Table 4: Parameter Validation

Beyond checking types, you often need to enforce real constraints — a minimum length, a numeric range, a regex pattern, a required-versus-optional rule. The modern Annotated syntax shown in the first rows is the recommended way to attach these rules while keeping the type and its metadata in one place. Push validation this far up the stack and your endpoint body can trust that the data is already clean.

Table 5: Pydantic Models and Validation

Pydantic models are the heart of how FastAPI validates and serializes structured data — a BaseModel subclass defines the shape of a request or response, and FastAPI does the rest. This table covers the tools for going beyond simple fields: per-field constraints, custom field and model validators for logic that types can't express, computed fields, and model inheritance for reuse. Note this is Pydantic v2, so model_config and field_validator replace the older patterns you may have seen.

Table 6: Response Configuration

Controlling what goes back to the client is just as important as parsing what comes in. The response_model and return-type annotation filter and validate your output — handy for stripping a password field before it ever leaves the server — while the various response classes let you return HTML, files, redirects, or streamed data instead of plain JSON. Status codes, custom headers, and cookies round out the toolkit for shaping a precise response.

Table 7: Dependency Injection

Dependency injection is one of FastAPI's most loved features — Depends() lets you factor out reusable logic like database sessions, authentication, and pagination, then declare it as a parameter wherever you need it. Dependencies can nest, run as yield generators that clean up after the response, apply at the route, router, or app level, and be swapped out entirely for testing. Lean on this pattern and your endpoints stay thin while shared concerns live in one place.

Table 8: Error Handling

When something goes wrong, you want a clean, consistent error response rather than a raw stack trace. Raising HTTPException is the everyday move for returning a 404 or 403, while custom exceptions paired with exception handlers let you centralize how whole categories of errors turn into responses. You can even override FastAPI's default validation-error format when you need errors shaped a particular way.

Table 9: Authentication and Security

FastAPI ships with security utilities that plug straight into its dependency system and its OpenAPI docs. The rows walk through the common building blocks — OAuth2 password flows, API keys in headers or cookies, JWT creation and verification, password hashing with bcrypt — and how they combine into a get_current_user dependency you reuse across protected routes. Security scopes at the end add fine-grained, permission-based access on top.

Table 10: Middleware

Middleware wraps every request and response, making it the right place for cross-cutting concerns that shouldn't live in individual endpoints. CORS is the one nearly everyone needs first, while the others handle compression, HTTPS enforcement, trusted-host checks, and sessions — plus the option to write your own function- or class-based middleware for custom logic like timing or request logging.

Table 11: Background Tasks

Some work — sending a confirmation email, writing a log — shouldn't make the user wait for the response. FastAPI's built-in BackgroundTasks handles the lightweight cases right inside the same process, no extra infrastructure required. For heavier or long-running jobs that need their own workers, the table points you to Celery and ARQ as the next step up.

Table 12: Database Integration

Most FastAPI apps talk to a database through SQLAlchemy, and the choice between async and sync sessions sets the tone for everything else. These rows cover defining ORM models, running queries the SQLAlchemy 2.0 way, injecting a session as a dependency so it closes cleanly after each request, and managing schema changes with Alembic. Connection pooling at the end is the detail that keeps a busy API from exhausting the database.

Table 13: WebSockets and Real-Time Communication

When you need a live, two-way channel — chat, notifications, a streaming dashboard — a plain request/response cycle won't do. FastAPI's WebSocket support gives you the full lifecycle: accept the connection, receive and send text or JSON in a loop, and handle the disconnect cleanly. The final SSE row is the simpler choice when updates only need to flow one way, from server to client.

Table 14: Testing

FastAPI makes testing genuinely pleasant because TestClient runs your app in-process — no server to spin up. These rows show the standard pytest workflow, the context-manager form that triggers lifespan events, the httpx-based async client for testing async code properly, and the dependency-override trick that swaps a real database for a mock without touching application code.

Table 15: Advanced Routing

As an app grows past a single file, APIRouter is how you split routes into focused modules with shared prefixes, tags, and dependencies, then mount them onto the main app. Sub-application mounting and static file serving extend the same idea, and the route-priority row captures a subtle gotcha — define /users/me before /users/{id}, or the parameterized route swallows it.

Table 16: OpenAPI Customization

FastAPI generates an OpenAPI schema and interactive docs for free, but real projects want to shape them. These rows let you set titles and descriptions, group endpoints under documented tags, add example responses, deprecate old routes, change or disable the docs URLs, and tweak Swagger UI behavior. Polishing the generated docs is what turns a working API into one other developers actually enjoy consuming.

Table 17: Settings and Configuration

Pydantic Settings brings the same type-safe validation you use for requests to your application config, reading values from environment variables and .env files and failing fast at startup if something's missing. Injecting settings as a dependency keeps them easy to mock in tests, and caching them with lru_cache means the config is parsed once. This is Pydantic Settings v2, so SettingsConfigDict replaces the old inner Config class.

Table 18: Performance Optimization

FastAPI is already fast, but these levers squeeze out more under real load. Writing I/O-bound handlers as async unlocks concurrency, Redis caching and HTTP cache headers cut repeated work, connection pooling protects the database, and ORJSON speeds up serialization. The deployment rows — Uvicorn workers, Gunicorn, and the Docker pattern — cover putting all of that into production across multiple CPU cores.

Table 19: Advanced Patterns

These are the extras you reach for once the basics are in place and the app is heading toward production. Rate limiting protects you from abuse, API versioning lets the interface evolve without breaking clients, and a GraphQL endpoint or class-based views fit specialized needs. Request-ID tracking and alternative serialization like MessagePack round out a toolkit for APIs that need to scale and be observable.