FastAPI Dependency Injection with Depends() Explained

Dependency Injection (DI) is one of the most important patterns used in production-grade FastAPI applications, yet it’s often misunderstood because it comes bundled with related (but different) concepts. Before you start using Depends(), it helps to understand what a dependency actually is, why injecting it from outside is better than creating it internally, and how this relates to the Inversion of Control principle. Once those ideas click, Depends() becomes the most natural thing in the world.

What is a Dependency?

A dependency is any object, resource, or service that a function or class needs in order to do its work. In a FastAPI application, your endpoints often depend on things like:

A database session
A repository or service class
The currently authenticated user
Configuration settings
An external API client
A logger

A dependency is simply something your code needs to do its job.

What is Dependency Injection?

Dependency Injection (DI) is a design pattern where a function or object receives its dependencies from an external source rather than creating them internally.

Without DI — tightly coupled

class StudentService:
    def __init__(self):
        self.printer = Printer()   # creates its own dependency

    def generate_report(self):
        self.printer.print("Student Report")

With DI — loosely coupled

class StudentService:
    def __init__(self, printer: Printer):
        self.printer = printer     # dependency provided from outside

    def generate_report(self):
        self.printer.print("Student Report")

printer = Printer()
service = StudentService(printer)  # inject it here

The service no longer creates its own dependency. This makes the code:

Loosely coupled — swapping Printer for a MockPrinter in tests requires no changes to StudentService
Easier to test — inject a mock or stub at will
Easier to reuse — the same service works with any compatible printer

What is Inversion of Control?

Inversion of Control (IoC) is a design principle where the responsibility for creating objects and managing application flow is delegated to a framework rather than your own code. Without IoC, your application code creates everything:

Application
    │
    ├── Create Database
    ├── Create Repository
    ├── Create Service
    └── Call Methods

With IoC, the framework takes over:

FastAPI
    │
    ├── Create Database
    ├── Create Repository
    ├── Resolve Dependencies
    └── Call Your Endpoint

Concept	Type	Answers
IoC	Design Principle	”Who controls object creation and application flow?” → The framework.
DI	Design Pattern	”How are dependencies provided?” → From outside, not created internally.

Is Dependency Injection the same as Inversion of Control?

No. They are related but different concepts.

IoC is a design principle — it describes who is in control of the application’s workflow and object lifecycle.
DI is a design pattern — it describes how dependencies are provided to objects.

DI is one of the most common techniques used to achieve IoC, but IoC can exist without DI (using callbacks or events) and DI can exist without IoC (manual injection where your code still controls creation).

Is FastAPI already using DI before I use Depends()

Yes. Even before you use Depends(), FastAPI already injects values into your endpoint functions:

@app.get("/students/{student_id}")
def get_student(student_id: int, active: bool = True):
    return {"student_id": student_id, "active": active}

For GET /students/101?active=false, FastAPI automatically injects:

student_id = 101 (from the path)
active = False (from the query string)

You never write this extraction code yourself. Depends() extends this same mechanism to inject higher-level application resources.

FastAPI’s `Depends()`

FastAPI provides a built-in DI system through the Depends() function. When a request arrives, FastAPI:

Resolves the dependency (calls the provider function)
Injects the result into the endpoint
Cleans it up after the request completes (if you use yield)

from fastapi import Depends, FastAPI

app = FastAPI()

def get_db():
    # In a real app: open a database session
    return {"connection": "active"}

@app.get("/students")
def get_students(db=Depends(get_db)):
    # db is automatically created and injected
    return {"db_status": db["connection"]}

Common Dependency Patterns

Database Session Dependency

from fastapi import Depends

def get_db():
    db = SessionLocal()  # open session
    try:
        yield db         # inject into endpoint
    finally:
        db.close()       # clean up after request

@app.get("/employees")
def list_employees(db=Depends(get_db)):
    return db.query(Employee).all()

The yield pattern ensures the session is always closed, even if the endpoint raises an exception.

Current User Dependency

from fastapi import Depends, HTTPException, status
from fastapi.security import HTTPBearer

bearer_scheme = HTTPBearer()

def get_current_user(credentials=Depends(bearer_scheme)):
    # Decode JWT and retrieve user
    token = credentials.credentials
    user = verify_and_decode_token(token)
    if not user:
        raise HTTPException(status_code=status.HTTP_401_UNAUTHORIZED, detail="Invalid token")
    return user

@app.get("/profile")
def get_profile(current_user=Depends(get_current_user)):
    return {"user": current_user.username}

Reusable Typed Dependencies with `Annotated`

Use Annotated to define a reusable dependency alias once and use it everywhere:

from typing import Annotated
from fastapi import Depends

# Define once
DbDep = Annotated[Session, Depends(get_db)]
CurrentUserDep = Annotated[User, Depends(get_current_user)]

# Use everywhere
@app.get("/employees")
def list_employees(db: DbDep, current_user: CurrentUserDep):
    return db.query(Employee).all()

@app.post("/employees")
def create_employee(employee: EmployeeCreate, db: DbDep, current_user: CurrentUserDep):
    ...

Dependency Resolution Flow

HTTP Request
      │
      ▼
FastAPI
      │
      ▼
Resolve Dependencies
      │
      ├── get_db()
      ├── get_repository()
      ├── get_service()
      └── get_current_user()
      │
      ▼
Inject into Endpoint
      │
      ▼
Execute Endpoint
      │
      ▼
Cleanup (yield-based dependencies)

FastAPI resolves dependencies in the correct order — if get_service() depends on get_db(), FastAPI calls get_db() first, then passes the result to get_service(), then injects the service into your endpoint. You never manage this order manually.

What FastAPI Can Inject

Resource	Dependency Pattern
Database session	`get_db()` with `yield`
Repository / Service	Constructor injection via `Depends`
Current authenticated user	`get_current_user()` with token verification
Configuration / settings	`get_settings()` returning a `Settings` instance
External API client	`get_http_client()`
Logger	`get_logger()`

Benefits

Using Depends() across your application delivers:

Loose coupling — endpoints don’t know how their dependencies are created
Testability — override any dependency with a mock in tests using app.dependency_overrides
Reusability — define a dependency once, inject it in dozens of endpoints
Automatic lifecycle management — yield dependencies are always cleaned up
Composability — dependencies can themselves depend on other dependencies

To override a dependency in tests:

def mock_get_db():
    yield fake_db_session

app.dependency_overrides[get_db] = mock_get_db

This replaces the real database with a test fixture for the duration of your tests — no changes to your production code required.

SQL & Databases

Data Analysis

FastAPI

Frontend

FastAPI Dependency Injection with Depends() Explained

What is a Dependency?

What is Dependency Injection?

Without DI — tightly coupled

With DI — loosely coupled

What is Inversion of Control?

FastAPI’s `Depends()`

Common Dependency Patterns

Database Session Dependency

Current User Dependency

Reusable Typed Dependencies with `Annotated`

Dependency Resolution Flow

What FastAPI Can Inject

Benefits

​What is a Dependency?

​What is Dependency Injection?

​Without DI — tightly coupled

​With DI — loosely coupled

​What is Inversion of Control?

​FastAPI’s Depends()

​Common Dependency Patterns

​Database Session Dependency

​Current User Dependency

​Reusable Typed Dependencies with Annotated

​Dependency Resolution Flow

​What FastAPI Can Inject

​Benefits

What is a Dependency?

What is Dependency Injection?

Without DI — tightly coupled

With DI — loosely coupled

What is Inversion of Control?

FastAPI’s `Depends()`

Common Dependency Patterns

Database Session Dependency

Current User Dependency

Reusable Typed Dependencies with `Annotated`

Dependency Resolution Flow

What FastAPI Can Inject

Benefits