FastAPI Dependency Injection for Anthropic Claude: Isolating API Keys and Rate Limits Per Tenant When CitizenApp hit 15 tenants, I realized our single global Claude API key was a ticking time bomb.
One customer's agentic loop burning through their quota would throttle everyone else.
Worse, we had no way to enforce per-tenant rate limits without adding middleware spaghetti that would make debugging a nightmare.
The fix?
Lean into FastAPI's dependency injection system to make tenant-specific Claude clients and rate-limit buckets first-class citizens.
No globals, no thread locks, no "who's using the API key right now?" detective work.
Why Not Middleware or Global State?
Middleware runs once per request, which means you'd have to either: Parse the tenant ID from the request, look up their key, then store it somewhere accessible (request state, context vars, thread-local storage) Hope that concurrent requests don't collide when accessing shared rate-limit buckets I've been burned by this.
We had a middleware that set , but then handlers had to manually fetch the API key and pass it around.
When we added background tasks that queried Claude, the entire pattern fell apart—context vars leaked, rate limits weren't enforced, and debugging which tenant was which took hours.
FastAPI's Depends system solves this cleanly: dependencies are resolved per-request (or per-dependency cache if you use ), and they compose naturally.
Your handler doesn't care how it gets a Claude client—it just declares what it needs.
The Setup: Tenant-Aware Dependency Providers Let's start with the data layer.
You need a way to fetch tenant configuration and manage rate limits: Now the dependency providers: Using It in Handlers Now your handlers are clean and testable: Why This Works Isolation: Each tenant's API key and rate limit are independent.
One tenant's quota exhaustion doesn't touch another's.
Composability: Dependencies depend on other dependencies. depends on , which depends on .
You can test each layer independently.
Reusability: If 10 handlers need Claude, they all get the same tenant-specific client without duplication.
Async-safe: FastAPI resolves dependencies per-request.
No thread-local trickery, no accidental state sharing between concurrent requests.
Gotcha: Caching Pitfalls I initially used on to avoid DB hits.
Don't.
If a tenant's API key rotates mid-day, cached tenants still have the old key.
Instead: The DB query is cheap.
Stale credentials are expensive.
Scaling to Redis For distributed deployments with multiple FastAPI instances, replace in-memory buckets with Redis: