Skip to main content
Memic has a four-level hierarchy. Most of the time you only need to think about two levels: environments and folders. The rest is dashboard plumbing you set up once.
Memic hierarchy: Organization → Project → Environment → Folder

​
The hierarchy

​
Organization

The top level. An organization represents your company or team. Members belong to an organization. Billing and user management live here. You create organizations from the Memic dashboard, not the API.

​
Project

A project is a product or workload inside an organization. If you’re running three different AI products on Memic, you’d have three projects. Each project is isolated from the others — files in Project A are never visible to Project B.

​
Environment

An environment is where your data actually lives. Every file, every vector, every search query is scoped to exactly one environment. Typical layout:
  • staging — for testing and preview
  • production — for live traffic
  • One environment per customer if you’re building a multi-tenant product
Environments are the tenant-isolation boundary. Data in one environment cannot be queried from another, ever. This is the core multi-tenancy guarantee.

​
Folder

Folders organize files within an environment. Think of them like directories in a filesystem — they’re purely organizational and have no impact on retrieval. You can search across all folders or filter to specific ones.

​
API keys: the single piece of context you need

Every Memic API key is bound to one environment. When a request arrives, Memic resolves the full context (org, project, environment) from the key alone. That’s why API URLs don’t need IDs in the path: 
# You don't write this:
POST /api/v1/organizations/{org_id}/projects/{project_id}/environments/{env}/search

# You write this:
POST /api/v1/search
Rotating environments is a key swap. To move from staging to production, you change the API key — nothing else in your code changes.

​
Common patterns

​
Per-customer isolation

If you’re running a multi-tenant SaaS where each customer needs their own knowledge base, create one environment per customer. Each customer gets their own API key. Customer A’s data can never leak into Customer B’s queries because the keys are bound to different environments. See the Per-customer isolation recipe.

​
Staging vs production

The simplest pattern: two environments (staging and production), two keys, same codebase. Point at staging during dev and CI, point at production in your live deploy.

​
A single global environment

If you’re just getting started or building an internal tool, a single environment called production is fine. You can always add more later.

​
What’s next?

Python quickstart

Install the SDK and make your first call.

Authentication

How API keys resolve context.