r/FastAPI

Spent the last stretch building out a fairly complete SaaS backend in FastAPI - auth, Stripe billing, multi-tenant teams - and wanted to share a few things that weren't obvious going in, in case they save someone else a debugging session.

1. Refresh token rotation needs to be atomic, not just "issue a new one". If you check the token's validity and then invalidate it as two separate DB operations, concurrent requests with the same token can both pass the check. You want a single conditional update (UPDATE tokens SET used = true WHERE token = :t AND used = false) and branch on rows-affected. Bonus: once rotation is atomic, an already-rotated token being presented again is a replay signal, and you can revoke the whole token family.

2. Stripe webhook idempotency has to be enforced at the DB layer, not an in-memory cache. Stripe documents that the same event can be delivered more than once. Unique constraint on event.id, insert before you process, treat a constraint violation as "already handled, return 200". Do the state mutation and the event-id insert in the same transaction so a crash mid-request can't leave you half-processed.

3. If you build outbound webhooks for your own customers, steal Stripe's signing scheme instead of inventing one. Sign f"{timestamp}.{payload}" with HMAC-SHA256 per customer, send as t=<ts>,v1=<sig>. Verifying the timestamp is what makes it replay-proof. Build retries with backoff and a delivery log from day one - "did my webhook fire" is a support question you will get on day two.

4. RBAC for multi-tenant apps is a join table, not a role column on the user. membership(user_id, org_id, role). Enforce role checks as a FastAPI dependency that resolves (user, org_id) -> membership, not inline in each route, or you'll eventually forget the check on route #37.

None of this is exotic - it's the difference between "demos fine" and "survives concurrent load and a hostile actor". Happy to go deeper on any of these, and genuinely want to know if there's a cleaner pattern for the RBAC dependency design.

(I packaged all of this into a paid boilerplate called LaunchKit if anyone wants the implementation rather than the writeup: https://launchkit-orcin.vercel.app/)

Hi everyone,

Over the past several months I've been working on FastAPI Startkit, an open-source application framework that brings some of the development patterns I enjoyed in Laravel to Python and FastAPI.

The goal isn't to replace FastAPI—it's to provide a structured foundation for larger applications while remaining modular. You can install only the pieces you need.

Some features include:

• 🏗️ Service container & dependency injection
• ⚡ CLI similar to Laravel's Artisan
• 🗄️ Async ORM, migrations, and seeders
• 🧪 Built-in testing utilities
• 🤖 AI agent support with multiple LLM providers
• 🎨 Optional Vite integration for monolithic full-stack apps
• 📦 Works for FastAPI apps, background workers, or even CLI-only applications

One design goal was to avoid forcing everything into a single opinionated stack. Most components are optional, so you can start small and add features as your project grows. The documentation also includes both a minimal setup and a more structured project layout.

Documentation:
https://fastapi-startkit.github.io/

I'd really appreciate feedback on:

• Is the architecture intuitive?
• Which parts feel over-engineered?
• Are there features you'd expect in a production-ready FastAPI framework that are missing?
• Any suggestions for improving the developer experience?

Constructive criticism is very welcome. Thanks!

A FastAPI endpoint that verifies Stripe's signature, then routes each event type to the right billing action.

Three takeaways

1. Always verify a webhook's signature against a shared secret before trusting its contents.
2. Read the raw request body for signature checks — parsed JSON won't match the signed bytes.
3. Return 200 quickly and delegate the actual work so the provider considers the event delivered.