Skip to main content
Buckets are custom topical categories for a profile — an axis that sits alongside static and dynamic. Where static/dynamic split facts by how long-lived they are, buckets group them by subject (e.g. preferences, goals, work). As content is ingested, a classifier assigns each memory to the buckets it matches, so you can pull just the slice of context a given surface needs.
New to buckets? Read the conceptual overview first — this page is the API reference for reading, creating, and managing them.
Every org starts with a built-in preferences bucket. You can define your own at the organization level, and add more per namespace (what v3/v4 called a container tag) — all covered below.

Reading buckets

Requesting bucketed profiles

supermemory.profile returns buckets next to static and dynamic. Omit buckets in the request to get every effective bucket, or pass up to 50 names to narrow only the bucket section.
Response:
[Recent] and [Summary] labels. To keep profiles dense, an entity’s older memories are periodically aggregated into a short synthesis. Entries prefixed [Summary] are that aggregated context; entries prefixed [Recent] were ingested since the last aggregation and aren’t summarized yet. The dynamic section uses the same [Recent] prefix (plus a [YYYY-MM-DD] date). Strip the prefixes if you only want raw text, or keep them to signal recency to your model.

List bucket definitions

To see which buckets are configured for a namespace (org buckets merged with any namespace-level additions), call profiles.getBuckets:
Response:

Creating and configuring buckets

Bucket definitions live at two levels: organization (the default set every namespace gets) and namespace (per-namespace additions). Namespace buckets are managed through profiles.setBuckets and profiles.deleteBuckets.

Namespace buckets

setBuckets sends 1 to 50 name-to-description entries. Existing namespace names are updated, new names are added, and omitted namespace buckets remain unchanged. These are add-only on top of org buckets — a namespace always keeps every org bucket, and if a namespace bucket’s name collides with an org bucket, the org’s definition wins in the merged, effective set used at ingestion and read time.

Delete namespace buckets

Organization-owned buckets appear in the effective getBuckets response but cannot be changed or removed through namespace setBuckets or deleteBuckets calls. Organization-level buckets are managed in the console, not through the v5 API.

Starter presets

If you’d rather start from a template than write descriptions from scratch, these are the same presets available in the console UI:

Default bucket

If neither the org nor the namespace has configured any buckets, ingestion falls back to a single built-in preferences bucket, scoped tightly to explicit first-person statements (“prefers X over Y”, “always uses W”) — not inferred traits or general observations. Configuring your own buckets replaces this default.

Validation & limits

Bucket descriptions steer classification. A precise description (“Explicit first-person preferences only — exclude inferred traits”) yields cleaner buckets than a vague one.

Configure

Instructions

Bucket descriptions only steer classification within a bucket — they don’t tell the model anything about the namespace itself. For that, set supportingContext on the namespace: a free-text field that’s appended alongside the org-level organizationalContext into the same prompt the extraction/classification step uses, so it shapes bucket assignment too, not just fact extraction.
supportingContext is per-namespace, so use it for context specific to that user/namespace (who they are, what the namespace is for) — use org-level organizationalContext for guidance that should apply everywhere. Both are combined into the same prompt, so keep them complementary rather than redundant.
You can also set supportingContext inline when adding content, via supportingContext in the body of supermemory.add — useful if you don’t want a separate namespace call.

Model selection

The model behind extraction and bucket classification isn’t configurable through the API on supermemory Cloud — it’s managed for you. If you’re self-hosting, you choose the provider and model yourself via environment variables (OPENAI_MODEL and related) — see Self-hosting Configuration.

Next steps