> ## 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.

# Core concepts

> Organizations, projects, environments, folders — and how a single API key resolves all of them.

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.

<Frame>
  <img src="https://mintlify.s3.us-west-1.amazonaws.com/memic/images/hierarchy.svg" alt="Memic hierarchy: Organization → Project → Environment → Folder" />
</Frame>

## 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:

```bash theme={null}
# You don't write this:
POST /api/v1/organizations/{org_id}/projects/{project_id}/environments/{env}/search

# You write this:
POST /api/v1/search
```

<Check>
  **Rotating environments is a key swap.** To move from staging to production,
  you change the API key — nothing else in your code changes.
</Check>

## 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](/recipes/per-customer-isolation).

### 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?

<CardGroup cols={2}>
  <Card title="Python quickstart" icon="python" href="/quickstart-python">
    Install the SDK and make your first call.
  </Card>

  <Card title="Authentication" icon="key" href="/api-reference/authentication">
    How API keys resolve context.
  </Card>
</CardGroup>