Skip to main content
Namespaces are the tenancy boundary in Deyta Platform. Every memory belongs to exactly one. Common patterns:
  • One namespace per end user — you build a personal-memory product
  • One namespace per project or workspace — you build a team product
  • One namespace per data source — you keep ingested content from different sources separate
  • A small fixed set — you build an internal tool with a handful of long-lived stores
You can mix patterns. Namespaces are cheap; create as many as your application needs.

​
Creating a namespace

Open Namespaces in the console sidebar and click Create namespace. You’ll be asked for:
FieldPurpose
NameHuman-readable label. Shown across the console; not a unique identifier.
DescriptionOptional, for your team’s reference.
External reference IDOptional. Your own ID for this namespace — useful when Deyta Platform should be addressable by your user/project ID rather than the Deyta Platform-generated ns_….
You can also create namespaces programmatically — see Create a namespace in the API reference.

​
Listing and finding

The namespaces page is the index. From there you can:
  • Search by name or description
  • Group by scope value, by recent activity, or none
  • Filter by scope, if your org uses scopes
For very large catalogs, consider creating a few top-level namespaces and using scopes within them rather than thousands of individual namespaces — the console UX is happier at moderate counts.

​
Detail view

Clicking into a namespace shows you:
  • Stats — document count, chunk count, entity/relationship count, last activity
  • Recent activity — the last few remember / recall / forget events
  • Ingestion jobs — if any data sources are connected, the most recent sync runs
  • Permissions — which users and API keys have access
  • MCP endpoint URL — for connecting an agent directly via Model Context Protocol

​
Permissions

Namespaces have dual grants: both users (people in your org) and API keys can be granted access. From the namespace detail page, open the permissions panel to:
  • Grant a user access (read-only or read/write)
  • Grant or revoke an API key
  • Remove a grant
Grants cascade-delete with the namespace — there’s no orphan permission cleanup to do.
Granting a user read/write lets them call forget from any tool that uses their session. There is no per-operation confirmation.

​
External reference IDs

If you set external_reference_id on a namespace, every operation that takes a namespace can address it by that ID instead of the Deyta Platform ns_…: 
curl https://api.deyta.ai/gateway/v1/recall \
  -H "Authorization: Bearer $DEYTA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "external_reference_id": "user-abc-123",
    "query": "hello"
  }'
This means your application can drive Deyta Platform using its own user/project IDs without keeping a separate mapping table.

​
Deleting a namespace

From the detail page, open the kebab menu and choose Delete. Deletion is permanent and removes:
  • All documents, chunks, entities, and relationships in the namespace
  • All ingestion connections rooted in this namespace
  • All permission grants for users and API keys
There is no soft-delete. Take an export first if you need one.

​
Auto-provisioning (for some orgs)

Some plans enable auto-provisioning — when an API key calls a memory operation with an external_reference_id that doesn’t exist yet, the namespace is created on the fly. If your org has this enabled, you’ll see a banner in the namespaces page; if not, every namespace must be created explicitly first.

​
What’s next

Authentication

API keys, permissions, and namespace grants.

Admin

Org-wide controls — members, ontology, integrations, audit log.