MemorySyncMemorySync
Guides

Multi-tenant Setup

MemorySync isolates data on three axes: organization → project → environment. Pick the granularity that matches your trust boundary.

Hierarchy

Common patterns

Pattern 1: One project per workload

Best for most teams. The chatbot project does not see internal RAG memories. Used when your apps are unrelated.

Pattern 2: One project, end-user isolation

Use a single project but pass X-End-User-ID on every request. Recall is scoped automatically. Cheaper to operate; useful for B2C apps.

Pattern 3: Project-per-customer (B2B SaaS)

Provision a project per paying customer via POST /org/projects. Strongest isolation; matches typical B2B contractual requirements.

API keys

  • Each key is bound to one project + one environment. Prefix tells you which: ms_live_*, ms_test_*, ms_dev_*.
  • Scopes are restrictive by default. Recommended split: memory:read,memory:add for runtime, memory:* for back-office tasks.
  • Keys hash on creation; the plaintext is shown only once. Rotate via POST /org/api-keys/{id}/rotate.

Step-by-step

  1. Create the project: POST /org/projects with { "name": "Acme Support Bot" }.
  2. Create environments (dev/staging/prod) — at least production exists by default.
  3. Create at least one API key per environment with the right scope set.
  4. Set per-project quotas at /settings/billing (or via the budgets API).
  5. Enable connectors at the project level. Connectors only sync into their own project.

Cross-project recall (rarely used)

Set X-Allow-Cross-Project: true on a query and the API key carries the org:cross_project_read scope. Useful for org-wide search dashboards. Not recommended for runtime LLM calls.

Heads up
Vector search uses a project_id partition key. Cross-project recall does N partitions worth of work; expect 2–5× the latency.

Enterprise considerations

  • SCIM groups can be mapped to per-project roles via scim_group_mappings.
  • Audit logs are written at every level (org, project, env) and forwarded to your SIEM if configured.
  • Per-org KMS keys can be enabled to satisfy BYOK requirements; embeddings are still generated using the shared inference fleet.