Skip to main content
Most apps built on Supermemory serve more than one user, customer, or tenant out of a single Supermemory organization. Multi-tenancy is how you keep those memories apart — so User A’s data is never visible to User B, and so you can still slice and query within a user’s own data by things like category, status, or date. Supermemory gives you two complementary tools for this:

Container Tags

Isolation. A container tag is a hard boundary — its own namespace. Memories in one tag are never returned by a search scoped to another tag.

Metadata Filtering

Organization. Metadata is a set of custom key/value properties on a memory that you filter by — category, priority, date, participants, anything you define.
They solve different problems, and most production apps use both together.

​
Why two mechanisms

It’s tempting to reach for one tool and make it do everything, but tags and metadata aren’t interchangeable — they answer different questions. A container tag decides whether a memory is reachable at all for a given request. Metadata decides which of the reachable memories match. Filtering never crosses a container tag boundary — you can’t use metadata to peek into another tenant’s container.

​
How they work together

A typical multi-tenant write scopes the memory to a tenant with a container tag, then attaches metadata for finer-grained querying later:
And a search combines both: the container tag restricts which tenant’s data is in scope, and filters narrow down which memories within that tenant come back:
Container tags are required for isolation and validated as an access boundary. Metadata filters are optional — a search with just containerTag and no filters still only returns that tenant’s memories.

​
Choosing your boundary

Container tags are the layer that should map to your actual tenancy model — pick the level that matches what “one isolated space” means in your app: Everything within that boundary — categories, statuses, dates, custom fields — is metadata, not a new tag. Don’t create a new container tag for every property you want to filter on; that’s what metadata is for.

​
Access control

Container tags aren’t just organizational — they’re enforced as an authorization boundary. API keys and org members can be restricted to specific tags, so a request for a tag outside the caller’s allowed set is rejected with 403 Forbidden rather than silently filtered. See Container Tags → Access control for the details.

​
Next steps

Examples

Personal agents, company agents, email assistants, and support platforms.

Container Tags

How isolation works, naming rules, and access control.

Organizing & Filtering

Metadata filter types, combining AND/OR, and query limits.

Scoped API keys

Mint keys that can only touch one container tag.