If you’re building a product where each of your customers has their own knowledge base, you need strict isolation so Customer A’s documents never appear in Customer B’s queries. Memic’s environments are built for exactly this.Documentation Index
Fetch the complete documentation index at: https://docs.memic.ai/llms.txt
Use this file to discover all available pages before exploring further.
The pattern
- One environment per customer. When a customer signs up, create a new environment in your Memic project.
- One API key per environment. Each environment gets its own key.
- Store the key mapping server-side. In your own database, map each customer to their Memic API key.
- Swap keys per request. On every request, load the authenticated user’s customer record, look up their Memic key, instantiate a Memic client with that key.
Schema
Your database needs something like:Provisioning flow
When a new customer signs up:Environment and API key creation uses Memic’s management API. This is not
part of the public
/api/v1/* surface — contact Memic for access to the
management API if you need to automate provisioning.Request flow
/search uses a fresh Memic client bound to the
authenticated user’s customer environment. Cross-tenant queries are
structurally impossible.
Testing the isolation
In your test suite, assert that cross-customer queries return nothing:Going further
- Key rotation: when a customer asks to rotate, create a new key, update your DB, delete the old key in the Memic dashboard
- Soft-deleting customers: don’t delete the Memic environment until your compliance/retention window expires; then delete via the dashboard
- Analytics: aggregate per-customer stats in your own DB rather than trying to slice Memic’s usage — Memic doesn’t expose per-environment usage metrics in the public API