★ Enterprise Edition — not included in the Community Edition. Compare editions

AI-Powered Search¶

Search your emails by meaning, not just keywords.

The RAG (Retrieval-Augmented Generation) service (container port 8090, published on host port 8091) turns email content into vector embeddings stored in a Qdrant vector database. Searches embed the query the same way and rank stored vectors by cosine similarity — semantic search that works even when you don't use the exact words from the email.

How it works¶

flowchart LR
    subgraph Indexing
        A[Email content\nvia API] --> B[Chunk text]
        B --> C[Generate embeddings]
        C --> D[Store in per-org\nQdrant collection]
    end

    subgraph Searching
        E[Search query] --> F[Embed query]
        F --> G[Cosine similarity\nsearch in Qdrant]
        G --> H[Ranked results]
    end

    D -.->|same collection| G

1. Chunking. Long emails are split into chunks (default 1,000 characters, 200-character overlap).
2. Embedding. Each chunk becomes a dense vector. The default provider (sentence_transformers, model all-MiniLM-L6-v2) runs locally — email content never leaves your infrastructure. OpenAI, Azure OpenAI, HuggingFace, and Ollama backends are supported via configuration.
3. Storage. Vectors land in Qdrant, one collection per organization ({prefix}_{org_id}_{type}, e.g. mailrag_org123_emails).
4. Search. The query vector is compared against the org's collection; matches return with relevance scores.

Configuration¶

Core settings¶

Qdrant settings¶

Embedding settings¶

Chunking and search¶

API endpoints¶

Via the platform API (authenticated with X-API-Key, org-scoped)¶

The real gateway routes (see RAG System for bodies and details):

POST /api/v1/rag/search                          # semantic search
GET  /api/v1/rag/rag/index/status/{domain}
POST /api/v1/rag/rag/index/trigger
GET  /api/v1/rag/collections/{domain}
POST /api/v1/rag/collections/{domain}
GET  /api/v1/rag/collections/{domain}/stats
POST /api/v1/rag/documents/{collection_id}       # add documents
GET  /api/v1/rag/organizations/{org_id}/collections
GET/PUT /api/v1/rag/organizations/{org_id}/rag/config
GET  /api/v1/rag/organizations/{org_id}/rag/stats
GET  /api/v1/rag/organizations/{org_id}/rag/documents
POST /api/v1/rag/organizations/{org_id}/rag/reindex
GET  /api/v1/rag/health

Direct service endpoints (compose network / host port 8091)¶

GET  /api/v1/organizations/                             # list org RAG configs
GET/POST/DELETE /api/v1/organizations/{org_id}/config   # per-org indexing config
GET  /api/v1/organizations/{org_id}/indexing-status
POST /api/v1/organizations/{org_id}/reindex
GET  /api/v1/organizations/available-fields             # what can be indexed
GET  /health/                                           # Qdrant + embedding health
GET  /config                                            # effective configuration
GET  /admin/collections, /admin/metrics, /admin/embedding/models, ...

Interactive OpenAPI docs are served at /docs on the service.

Things to know¶

• Vector size follows your embedding model — derived automatically; see the note above. Switching models still means re-indexing everything; vectors from different models are not comparable.

• Privacy mode is on by default. With EMBEDDING_PRIVACY_MODE=true the service refuses cloud embedding providers. Turn it off explicitly (and set the provider + API key) to use OpenAI or Azure.

• Multi-tenancy is collection-per-org. Search is scoped to the requesting organization's collection; Org A cannot find Org B's content. Collections are created on demand at first index.

• Qdrant needs its own resources. Vector indices live in RAM for fast search — roughly 1.5 GB per million 384-dimensional vectors. In production Qdrant is bound to loopback (127.0.0.1:6333).

• RAG operations emit webhooks — rag.indexing.started, rag.indexing.complete, rag.search.complete, and rag.ai.transaction flow through the webhook system.