Skip to main content
Every API request is tied to one workspace. There are two ways to authenticate, and each resolves the workspace, the caller, and the granted scopes from the credential itself — never from anything in the request path, query, or body.

​
API keys

An API key is a bearer credential for one workspace. Keys look like this:
Send the key in the Authorization header on every REST request:

​
Create a key

Issuing keys is an Admin and Owner action. Find it in the dashboard under Settings → API Tokens.
When you create a key you choose:
  • A name, so you can recognize it later.
  • The scopes it grants. With no scopes selected, a key gets the read-only default.
  • An optional expiry.
The key’s full value is shown once, at creation. Store it somewhere safe — Glean Feed keeps only a hash and cannot show it again. If you lose it, rotate the key.
Treat keys like passwords. Never commit them to source control, paste them into client-side code, or include them in screenshots. A leaked key has whatever access its scopes allow until you revoke it.

​
Revoke and rotate

Revoke a key from the dashboard to cut off access immediately — the next request with that key fails with 401. Rotating a key revokes the old value and issues a new one with the same name and scopes. A key’s authority tracks the member who created it. If that member is removed from the workspace, keys they created are revoked and the next request fails with 401.

​
OAuth for the CLI and assistants

The Glean Feed CLI and AI assistants use OAuth instead of asking a person to copy a static API key. The client sends you to a Glean Feed approval screen where you can sign in or sign up, pick the workspace, and approve the scopes it requested. Glean Feed issues a token bound to that one workspace, your identity, and the approved scopes. OAuth tokens can authenticate both REST and MCP; API keys remain REST-only. You manage connected assistants under Settings → MCP, where you can revoke any client’s access. For setup steps, see Connect over MCP.

​
OAuth request bodies

The CLI and supported assistants handle the OAuth flow for you. If you are implementing a client directly, use the advertised OAuth metadata and send token requests as JSON, application/x-www-form-urlencoded form data, or multipart/form-data. Unsupported token request body types return an OAuth invalid_request response, and malformed form bodies are handled without exposing server parser details. Token revocation stays idempotent: malformed, unknown, or already-revoked token requests return success without revealing whether a token matched.

​
How Glean Feed chooses the workspace

Whichever method you use, the workspace is fixed by the credential. Passing a different workspace id or slug in a request has no effect on which workspace you reach — the credential decides. A request for a resource in another workspace returns 404, the same as a resource that does not exist.

​
Next steps

https://mintcdn.com/gleanfeed/XujswKjVl9A7LyQN/icons/key.svg?fit=max&auto=format&n=XujswKjVl9A7LyQN&q=85&s=bef0e09f655d6e92652b5049ef64ab72

Scopes

Choose the least access your integration needs.
https://mintcdn.com/gleanfeed/XujswKjVl9A7LyQN/icons/link.svg?fit=max&auto=format&n=XujswKjVl9A7LyQN&q=85&s=75ae28db135b545c47854a349f085815

Connect over MCP

Connect Claude, Cursor, or Codex.