> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.ovalbee.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.ovalbee.com/_mcp/server. # Secrets and API tokens ## Secrets A **secret** is a credential stored in the workspace for nodes to use — for example the address and API token of your Supervisely account, which every Supervisely node needs. Secrets are encrypted at rest, and their private values are never shown again after saving — not in the app, not to agents, not in exported flows. Manage them under **Settings** → **Secrets**. Each secret has a name and a **type**, such as *Supervisely* or *Email (SMTP)*, and the type decides which fields it has and which nodes can use it. Storage credentials are not secrets any more: a bucket of your own is connected under **Settings** → **Storage**, with its provider's credentials stored there. New *S3*, *Azure* and *Filesystem* secrets can't be created. Ones saved earlier stay in the list under their type, aren't read by any node, and can only be deleted. ### How nodes use them A node that needs a credential has a secret input, which lists only the secrets of the matching type. When the workspace has exactly one matching secret, a newly added node picks it for you. The value is handed to the node's run on the server, and the flow itself stores only which secret it uses. The **Last Used** column shows when a secret was last read by a run. To delete a secret that nodes still use, OvalBee asks you to pick a replacement and updates those nodes in the same step, so no flow is left pointing at a missing credential. When a flow is exported, secrets are referred to by name, and importing it into another workspace can re-link them to secrets with the same names there. ### Who can do what * **Owners** and **admins** create, edit and delete secrets. * **Developers** can see the list and use secrets in nodes. * Anyone who can edit a shared flow sees the names of the secrets it can pick from, never their values. ## API tokens An **API token** lets something outside the browser act as you: a script calling the OvalBee API, or an AI agent connected over MCP. Manage your tokens under **Settings** → **API Tokens**. #### Create a token Click **Create token** and give it a name that says where it will live, such as *build server* or *my laptop*. #### Copy it right away The token is shown once. OvalBee keeps only a fingerprint of it, so it can't be displayed again — create a new one if it's lost. #### Use it as a bearer token Send it in the `Authorization: Bearer ...` header of each request. A token belongs to one workspace and carries exactly **your** permissions there: if your role changes, so does what the token can do. There are no separate scopes, with one exception: a token can't manage API tokens, workspaces or your account (profile, email, password), so do that in the browser. Revoke a token with **Revoke token** in its row — it stops working immediately. The list shows when each token was created and last used. The **Build with your agent** dialog on the Home page creates a token for you when you connect Claude Code, Codex or another MCP client. See [Build with an AI agent](/build/agent). The [OvalBee CLI](/administration/cli) signs in with a token you store with `ovalbee auth login`. Tokens are also how you call [deployments](/concepts/models#deployments): requests to a deployment's endpoint are checked against the caller's token. Owners, admins and developers can create tokens. ## Related pages * [Members and roles](/administration/members-and-roles) — the roles referred to here. * [Build with an AI agent](/build/agent) — connecting an agent with a token. * [Audit log](/administration/audit-log) — token and secret changes are recorded.