Top 60 FastAPI Interview Questions (2026)

FastAPI is a modern Python framework for building APIs. It's built on Starlette for the async web layer and Pydantic for data validation, and it uses standard Python type hints to validate requests, serialize responses, and generate interactive docs.

The problem it solves: in older frameworks you wrote validation, serialization, and API docs by hand. FastAPI derives all three from your type hints, so you write less code, get fewer bugs, and get editor autocompletion for free.

Create an app instance with FastAPI(), decorate a function with a path operation like @app.get, return a dict, and run it with an ASGI server such as uvicorn. That's the whole minimal app: a few lines gives you a working JSON endpoint.

FastAPI serializes the returned dict to JSON automatically. The interactive docs appear at /docs with zero extra work.

A path parameter is part of the URL path, like /items/{item_id}, and identifies a specific resource. A query parameter comes after the ? in the URL, like /items?skip=0&limit=10, and usually filters, paginates, or sorts.

FastAPI decides which is which by name: if a function parameter's name appears in the route path, it's a path parameter, otherwise it's a query parameter.

A Pydantic model is a class that declares fields and their types. FastAPI uses it to validate incoming request bodies and to shape outgoing responses, so the types you write become the rules the API enforces at the edge, before any of your logic runs.

When you annotate a request parameter with a Pydantic model, FastAPI reads the JSON body, validates each field against the model, coerces types where it can, and hands you a typed object. If validation fails, it returns a 422 with a clear error list before your code ever runs.

You declare a parameter whose type is a Pydantic model. FastAPI reads the request body as JSON, validates it against the model, coerces types where it safely can, and hands you a typed instance. If validation fails, it returns a 422 before your code runs.

You don't parse the body yourself or call request.json(). The type annotation is the instruction: this parameter comes from the JSON body.

Use async def when the route awaits async I/O: an async database driver, an async HTTP client, or anything you call with await. Use plain def when the work is synchronous, because FastAPI runs def routes in a threadpool so they don't block the event loop.

The danger zone is putting blocking code inside an async def route. That runs directly on the event loop and stalls every other request. If your libraries aren't async, plain def is the safer choice.

FastAPI builds an OpenAPI schema from your routes, type hints, and Pydantic models, then serves two interactive UIs from it: Swagger UI at /docs and ReDoc at /redoc. Every path, parameter, and model you declare shows up automatically, with no separate documentation step.

You write nothing extra. Every path, parameter, request model, and response model you declare shows up in the docs, and you can try endpoints straight from the browser.

They map an HTTP method and a URL path to a function. @app.get('/users') handles GET requests to /users, @app.post('/users') handles POST, and there are matching decorators for put, delete, and patch. The decorated function becomes the handler FastAPI calls for that method and path.

The decorated function is the handler: FastAPI calls it, passes the validated parameters, and serializes what it returns to JSON.

response_model declares the Pydantic model FastAPI should use to shape and validate the response. You pass it in the decorator, like @app.get('/users/{id}', response_model=UserOut), and FastAPI serializes whatever your function returns through that model before it reaches the client.

The real value is filtering: if your internal model has a password hash, a separate UserOut response model guarantees it never leaks to the client, because FastAPI serializes only the fields the response model declares.

For the default success code, pass status_code in the decorator, like @app.post('/items', status_code=201). For errors, raise HTTPException with the status_code and a detail message, and FastAPI builds the JSON error response for you with the right status and body.

Returning a dict with an 'error' key does not change the status; it still sends 200. HTTPException is how you send a real 4xx or 5xx.

HTTPException is FastAPI's way to return an error response from anywhere in your code. You raise it with a status_code, a detail message, and optional headers, and FastAPI turns it into a JSON error with the correct status.

It short-circuits the request: nothing after the raise runs, and the client gets a clean, structured error.

Use Query from fastapi as the default value. Query lets you set constraints like min_length, max_length, ge, le, and a description, and mark the parameter required by giving it no default or the Ellipsis.

FastAPI enforces these before your function runs and reports failures as a 422.

Give the parameter a default value in the function signature. A query parameter with a default is optional, and one without a default is required, so FastAPI returns a 422 if the client leaves a required parameter out.

For optional values that can also be missing entirely, use a union with None and default to None, like q: str | None = None.

A route can return a dict, a list, a Pydantic model, a plain value, or a Response object. FastAPI runs the result through its JSON encoder, which knows how to serialize Pydantic models, datetimes, UUIDs, and more.

For full control over status, headers, or streaming, return a Response subclass like JSONResponse or StreamingResponse directly.

Pydantic checks each field against its declared type. Where it safely can, it coerces: the string '10' for an int field becomes 10. Where it can't, like 'abc' for an int, it raises a validation error.

You get typed, clean data inside your handler, and the client gets a precise 422 telling them which field was wrong.

uvicorn is an ASGI server. FastAPI is an ASGI application: it defines how to handle requests but doesn't listen on a socket itself. uvicorn is the process that binds to a port and drives the app.

In production you often run uvicorn workers behind a process manager or Gunicorn, and behind a reverse proxy like nginx.

WSGI is the older synchronous Python web server interface used by Flask and Django's traditional stack. ASGI is the async successor: it supports async handlers, WebSockets, and long-lived connections that WSGI's one-request-per-thread model can't express. FastAPI targets ASGI, which is why async comes built in.

FastAPI is ASGI, which is why it can run async routes and WebSockets natively. That's the technical reason it can do async where a plain WSGI framework can't.

Most of the time you don't: declaring typed parameters and Pydantic models is the FastAPI way. You reach for the Request object when you need something outside the declared parameters, like raw headers, the client IP, cookies you didn't declare, or the unparsed body.

Add request: Request to your signature and FastAPI injects it.

For form fields use Form, and for uploads use UploadFile with File. UploadFile streams large files to a spooled temporary location instead of loading them fully into memory, and it gives you an async read interface so big uploads don't exhaust RAM under load.

Form and JSON body can't be mixed in the same request, since they use different content types, so pick one per endpoint.

PUT replaces a resource with the full new representation, so the client sends every field. PATCH applies a partial update, so the client sends only the fields that change. In FastAPI you handle a partial update by reading the incoming model with exclude_unset so absent fields don't overwrite stored values.

The pattern is: load the stored item, call the update model's model_dump(exclude_unset=True), and merge only the provided keys.

You write a function (or callable) that returns what a route needs, then declare it as a parameter with Depends. FastAPI resolves it per request, runs it, and injects the result into your route.

Dependencies are the reuse mechanism: a database session, the current authenticated user, shared pagination params, all written once and pulled into any route. They can depend on other dependencies, and they make testing easy because you can override them.

A dependency can use yield instead of return to run cleanup code after the response. The code before yield is setup, the yielded value is injected, and the code after yield runs once the request finishes, even if it errored.

The classic use is a database session: open it before yield, close it after. It's FastAPI's equivalent of a per-request context manager.

Pydantic v2 rewrote the validation core in Rust, so it's much faster, and it renamed several APIs. Validators moved from @validator to @field_validator and @model_validator, Config class options moved to model_config, orm_mode became from_attributes, and .dict()/.json() became .model_dump()/.model_dump_json().

It matters because interviewers use it to gauge how current you are. Modern FastAPI ships on v2; knowing the renamed methods signals you've upgraded a real project.

Use @field_validator for a single field and @model_validator for cross-field checks. A field validator receives the value, runs your logic, and returns the cleaned value or raises ValueError, which FastAPI turns into a 422.

Field-level constraints (min_length, ge, pattern) go on Field; validators are for logic those constraints can't express.

Middleware wraps every request and response. You get the request before it hits any route and the response before it goes back to the client, so it's the place for cross-cutting concerns: logging, timing, adding headers, or catching everything.

Since FastAPI is built on Starlette, you write middleware the Starlette way, either as a function with @app.middleware('http') or a class.

Add CORSMiddleware to the app and list the allowed origins, methods, and headers. Without it, a browser frontend served from a different origin gets its requests blocked by the same-origin policy, even though the API itself is working fine.

Be specific with allow_origins in production. Using a wildcard '*' together with credentials is not allowed by the CORS spec and browsers will reject it.

BackgroundTasks run work after the response is sent, inside the same process. You add a task and return; FastAPI runs it once the client has its response. Good for quick fire-and-forget I/O like sending a confirmation email.

They are not a real task queue. There's no persistence, no retries, no separate workers, and heavy or CPU-bound work still ties up the process. For that, reach for Celery, RQ, or a message queue.

Use TestClient (built on httpx) with pytest. TestClient wraps your app and lets you make requests in-process without starting a real server, so you assert on status codes and JSON bodies in fast, isolated tests that run anywhere pytest runs.

Override dependencies with app.dependency_overrides to swap a real database for a test one, which is the payoff of putting the DB session behind Depends in the first place.

TestClient runs async routes fine for most cases because it drives the event loop for you. When you need to await things directly in a test, use httpx.AsyncClient with an ASGI transport and an async test runner like pytest-asyncio.

The rule: TestClient for the common request-response assertions, AsyncClient when the test itself must be async.

Wire the session through dependency injection. Create the engine and session factory once, then a get_db dependency that yields a session and closes it after the request. Inject that session into routes with Depends.

For sync ORMs like classic SQLAlchemy, use plain def routes so the blocking calls run in the threadpool. For async, use an async driver and SQLAlchemy's async session with async def routes.

An async def route runs on the single-threaded event loop. A blocking call, a sync database driver, time.sleep, a heavy CPU loop, holds the loop and prevents it from serving any other request until it finishes. Throughput collapses under load.

The fixes: use an async library so you can await instead of block, use a plain def route so FastAPI runs it in a threadpool, or push blocking work off the loop with run_in_executor.

Split routes into modules, each with its own APIRouter, then include them in the main app with app.include_router. You can set a shared prefix, tags, and dependencies per router, so an entire section inherits a URL prefix and its auth in one place instead of repeating it on every route.

This keeps a growing app organized: a users router, an items router, an auth router, each in its own file, all mounted in one place.

Use the security utilities. OAuth2PasswordBearer gives you a dependency that extracts the bearer token from the Authorization header. Write a get_current_user dependency that decodes and verifies the token (commonly a JWT) and returns the user, or raises 401.

Because it's a dependency, you attach it to any route that needs a logged-in user, and FastAPI runs the auth check before your handler.

Use Pydantic Settings (pydantic-settings). Define a Settings model whose fields map to environment variables, and Pydantic reads, validates, and types them at startup, optionally loading from a .env file. A missing or malformed variable fails loudly at boot instead of surfacing as a mysterious runtime error later.

Inject settings as a dependency, often cached with lru_cache so it's parsed once. Secrets come from the environment or a secret manager, never the repo.

Register a handler with @app.exception_handler for a specific exception type or a custom one. It receives the request and the exception and returns a Response, so you can produce a consistent error shape across the whole app.

This is how you turn a domain exception into a clean JSON error without try/except in every route.

Nest Pydantic models inside each other and use typed lists. A model field can be another model, or a list of models, and FastAPI validates the whole tree in one pass, reporting exactly which nested field failed if the incoming JSON doesn't match.

This is where declarative validation pays off: a deeply nested JSON body validates in one place, and the docs show the full structure.

Set title, description, and version on the FastAPI() constructor, add tags and summaries per route, and use response_model and status_code so the docs reflect reality. For deep changes, override app.openapi() to edit the generated schema.

Well-documented routes make the generated /docs genuinely useful to consumers, which is part of why teams pick FastAPI.

Return a StreamingResponse wrapping a generator or async generator. FastAPI sends chunks as they're produced instead of building the whole body in memory, which is right for big files, CSV exports, or server-sent events.

Set the media_type so the client knows what it's receiving.

Because FastAPI is ASGI, it supports WebSockets natively. You decorate a function with @app.websocket, accept the connection, then loop receiving and sending messages over a persistent, two-way channel. It's the base for chat, live dashboards, and push notifications where plain request-response HTTP falls short.

Unlike HTTP routes, a WebSocket handler is a long-lived connection, so you manage its lifecycle: accept, communicate, and handle disconnects.

Map HTTP methods to actions: GET reads, POST creates, PUT or PATCH updates, DELETE removes. The resources with nouns and plurals like /users and /users/{id}, return correct status codes, and keep GET requests side-effect-free so caches and retries stay safe.

FastAPI doesn't force REST, but the question expects you to design clean, predictable routes. Good status codes and resource naming are the visible signs of that.

An ASGI server (uvicorn) runs an asyncio event loop. Async def routes execute as coroutines on that loop, interleaving at each await point over OS-level I/O readiness. Plain def routes are pushed to a threadpool so their blocking calls don't touch the loop.

Nothing runs in parallel within one worker; it's cooperative concurrency on one thread plus a threadpool for sync work. Real CPU parallelism comes from running multiple worker processes.

Run multiple uvicorn worker processes (often via Gunicorn with the uvicorn worker class or uvicorn's own workers), roughly matched to CPU cores, behind a reverse proxy like nginx. Each worker has its own event loop, so processes give you the CPU parallelism async alone can't.

Beyond one box, put the app in containers and scale horizontally behind a load balancer, keep the app stateless, and move shared state to Redis or the database.

Keep it off the event loop. Options in ascending effort: run it in a threadpool with run_in_executor if the work releases the GIL (NumPy, some C libraries), offload to a separate process pool, or push it to an external worker system like Celery and return a job id the client polls.

The anti-pattern is doing heavy CPU work directly in an async route: it blocks the loop and every concurrent request stalls. Async is for I/O concurrency, not computation.

Use the lifespan context manager passed to FastAPI(). Code before the yield runs on startup (open a DB pool, warm a cache, load a model), code after the yield runs on shutdown (close connections). It replaces the older @app.on_event('startup'/'shutdown') hooks.

This is where you create resources that should live for the whole process, not per request.

Measure first: add timing, check the database, and look for the usual suspect, the N+1 query, where serializing each item triggers another lazy query. Then check for a blocking sync call sitting in an async route, missing pagination, and no response_model so you're serializing more than you send.

Fix in order of impact: eager-load or batch the queries, paginate, cache hot reads, and only then think about workers. The methodology (observe, hypothesize, verify, fix, confirm) matters more than any single tool.

Pydantic v2's Rust core made validation fast, but validating and serializing large or deeply nested payloads still costs CPU on every request. On hot paths that return big lists or wide objects, that per-request cost adds up and shows in your latency numbers.

Mitigations: use response_model_exclude to trim output, avoid revalidating data you already trust, consider a lighter serialization path for very hot endpoints, and don't wrap huge internal blobs in models when a plain dict serialized once is enough.

A dependency can itself declare dependencies, forming a tree that FastAPI resolves before your route runs. Within a single request, if the same dependency appears more than once, FastAPI calls it once and reuses the result by default; you can disable that with use_cache=False.

This lets you compose auth on top of a DB session on top of settings, cleanly, without re-running shared work.

Pass dependencies to APIRouter or to FastAPI() itself, or to include_router. Every route under that scope runs those dependencies, which is the clean way to enforce auth or rate limiting across a whole section without repeating Depends on each route.

These router-level dependencies run for their side effects (auth checks, logging); their return values aren't injected into the route.

The common approach is URL prefixes: mount a v1 router at /v1 and a v2 router at /v2, each its own set of routes and models. Header-based versioning is possible but less discoverable in the auto docs.

Keep old versions working while consumers migrate, and share unchanged logic between versions rather than forking everything.

Clarify the requirements first (per-user or per-IP, burst tolerance, single process or distributed), then pick the mechanism. Single process: a dependency or middleware holding a counter per key. Distributed: the state must live in Redis (atomic INCR with EXPIRE, or a token bucket in a Lua script), because per-process memory can't see global traffic across workers.

Return 429 with a Retry-After header on rejection, emit metrics on rejects, and put the check in a router-level dependency so it covers a whole section. Structuring the answer clarify, mechanism, storage, edges is what the question scores.

Use a dedicated response_model that declares exactly the public fields, and the parameters response_model_exclude, response_model_include, and response_model_exclude_none for finer control. A separate output model is the safest default because it can never leak an internal field.

The failure mode is returning the raw ORM object with sensitive fields; a response model closes that hole by construction.

With SQLAlchemy's async support, create an async engine and async session, and inject the session through a yield dependency using async with. Routes are async def and await every query. The whole path must be async: mixing a sync driver into an async session or forgetting an await is where bugs and blocking creep in.

If any part of your stack is only sync, it's often cleaner to run the whole endpoint as plain def and let FastAPI's threadpool handle the blocking, rather than half-migrating to async.

Validate all input (Pydantic already does the shape; add business rules), hash passwords with a strong algorithm, use short-lived tokens with proper verification, restrict CORS to known origins, and set security headers. Rate-limit auth endpoints, and never return stack traces to clients in production.

Also: use parameterized queries or an ORM to avoid injection, keep secrets in the environment or a secret manager, and put the app behind HTTPS terminated at the proxy.

app.dependency_overrides maps a real dependency to a fake one for the duration of a test. Swap the real database session for an in-memory or transactional test one, or the real current_user for a fixed test user, without touching route code.

This is the concrete payoff of dependency injection: production wiring and test wiring differ in one dictionary, not in scattered mocks.

Structured logging with a correlation id per request (set in middleware), metrics via a Prometheus client exposing a /metrics endpoint, and distributed tracing with OpenTelemetry instrumentation that ties spans across services. Middleware is the natural place to time requests and attach the request id.

The goal is that when an endpoint misbehaves in production you can see which request, how long each stage took, and where it called downstream, without adding print statements after the fact.

The ASGI server (uvicorn) stops accepting new connections on a shutdown signal and waits for in-flight requests to finish within a timeout, then runs the lifespan shutdown block to close pools and flush buffers. In containers, honor SIGTERM and set a sensible grace period so a deploy doesn't drop live requests.

For work that must not be lost, hand it to a durable queue rather than a BackgroundTask, since in-process background work dies with the process.

Split when parts of the system have different scaling needs, deploy cadences, or team ownership, not just because services sound cleaner. A FastAPI app scales fine as a well-structured monolith for a long time.

What breaks on splitting: a local function call becomes a network call that can fail and add latency, transactions no longer span services, and you inherit service discovery, retries, and distributed tracing. The production-ready answer weighs those costs against the benefit rather than defaulting to microservices.

Middleware wraps every request and response and is right for truly global concerns: request timing, a correlation id, catch-all error shaping, and response headers. A dependency is scoped and injectable: auth for specific routes, a per-request DB session, shared params.

Rule of thumb: if it applies to everything and touches the raw response, use middleware; if it produces a value a route needs or applies to a subset, use a dependency.

The generated OpenAPI schema is machine-readable, so you can generate typed client SDKs (TypeScript, Python, and others) directly from it, keeping frontend and backend contracts in sync. Contract tests and mock servers can be driven from the same schema.

That's a real productivity gain: the API contract is a single source of truth derived from your Python types, not a hand-maintained document that drifts.

Mark the route deprecated=True so it shows as deprecated in the docs, keep it working, and add the replacement alongside it. Communicate a timeline, emit metrics on the old route to see who still calls it, and only remove it once usage drops to zero.

Versioned prefixes make this cleaner: the old version keeps serving while the new one ships, and removal is a whole-version decision rather than a surprise.