Retrieval and multi-tenancy

Multi-Tenant RAG API

Personal build, open source2025

A document-QA backend where every tenant's data is walled off from every other tenant's — the first question any firm asks before handing over their files.

1
The problem

Most RAG demos assume one customer and one pile of documents. The moment a second tenant arrives, retrieval has to prove it can never reach across the boundary — and 'we filter the results' is not an answer a law firm will accept.

2
How it works

A FastAPI service where the tenant identity travels in a signed JWT and is resolved by middleware on every single request. Uploaded PDFs are parsed, chunked, embedded, and written into a vector collection scoped to that tenant; the chat endpoint can only ever query within the caller's own collection. Isolation is a property of the storage layout, not a filter applied afterwards.

3
What it proves

That per-tenant retrieval isolation, document ingestion, and a chat interface can sit behind one small, readable service — and that the pattern transfers directly to a firm that wants its own matters kept apart from everyone else's.

Built with
API
FastAPIPydantic SettingsUvicorn
Retrieval
ChromaDBsentence-transformersLangChain
Models
Google Gemini 1.5 Flash
Auth
JWT (python-jose)Bearer middleware
Ingestion
PyPDF2chunk + embed on upload
Next project

YouTube Sentiment Insights

Losing hours to work an AI system could handle?

Tell me about the process. I'll tell you straight whether it's worth automating — no pitch, no obligation.

Book a call