Skip to main content
There are two paths into Deyta Platform: humans signing in to the console, and applications calling the API with a key. They use different mechanisms.

​
Console sign-in

You sign in to the console through WorkOS — single sign-on, password, or magic link, depending on what your organization has enabled.
1

First time

Go to console.deyta.ai and sign in. New users land on a guided onboarding that creates the organization automatically.
2

Returning

Subsequent sign-ins land you in the organization you last used. If you belong to multiple, switch between them from the workspace switcher in the bottom-left of the sidebar.
All data in Deyta Platform is scoped by organization. A namespace, API key, or integration created in one org is invisible to another — even if the same person belongs to both.

​
API keys

Applications authenticate against the gateway API with a Bearer token. 
curl https://api.deyta.ai/gateway/v1/namespaces \
  -H "Authorization: Bearer $DEYTA_API_KEY"

​
Generate a key

In the console, open API Keys from the sidebar and click Generate Key. Give the key a recognizable name. The secret is shown only once — copy it immediately and store it as a secret in your application’s environment.

​
Rotate a key

Generate a new key, deploy your application with the new value, and then revoke the old one from the console. There is no in-place rotation — it’s a swap.

​
Revoke a key

Open API Keys, find the key, and revoke it. All requests using that key start failing with 401 UNAUTHORIZED immediately.

​
Permissions

Each API key carries a set of gateway permissions that gate what it can do. The most common ones:
PermissionAllows
NAMESPACE_READrecall, ask, list namespaces, get namespace by ID
NAMESPACE_WRITEremember, forget
NAMESPACE_MANAGECreate, delete, and grant access to namespaces
INTEGRATION_MANAGEList providers, start/complete/delete connections
Pick the smallest set that matches what your application actually does. A read-only chatbot doesn’t need NAMESPACE_WRITE.

​
Namespace grants

API keys are also granted to specific namespaces. Even with NAMESPACE_READ, a key can only see namespaces it’s been granted access to. Two ways a key gets a namespace grant:
  1. Implicit — when an API key creates a namespace via the gateway, it’s automatically granted to that namespace.
  2. Explicit — an admin grants access from the namespace’s permissions panel in the console.
Grants cascade-delete with the namespace.

​
Scopes (advanced)

Beyond namespace-level grants, API keys can be scoped to filter what content they see within a namespace. Scopes are key-value attributes attached to memories and to API keys; a key with the scope team=engineering will only see chunks tagged with that scope. Scopes are managed from the Scopes sidebar entry in the console. Most applications don’t need them — start without scopes and add them only when you need stricter isolation than namespace-level provides.

​
Identities (advanced)

If your application acts on behalf of an end user (e.g., personalizing memories per customer), use Identities to attach a stable user ID to every operation. The console’s Identities panel shows recent activity per identity for debugging and auditing. Identities are independent of API keys — one key can act as many identities by passing the identity ID on each request.

​
What’s next

Namespaces

Create and manage namespaces — the tenancy boundary for memories.

API Reference

Every gateway endpoint, with auth requirements documented per operation.