Skip to main content
A personal API token authenticates a script, a scheduled job or the MCP server exactly like a signed in session, without a browser.

​
Create a token

1

Open the API tokens card in Integrations

Sign in first. A token belongs to your account.
2

Name it after what will use it

A name such as backup-script or laptop-mcp makes revoking the right one possible later.
3

Choose a scope and an expiry

Read only is the default and is all a reporting script or the MCP read tools need. Choose read and write only for something that has to change data, such as a script, or an agent you allow to track keywords, manage competitors and update actions. An expiry of 30, 90 or 365 days beats a permanent credential sitting in a continuous integration configuration.
4

Copy the value immediately

The plaintext value, which starts with asob_, is shown once. asobeast stores only a SHA-256 hash of it and can never show it again.

​
Scope and expiry

The tokens card shows each token’s scope, expiry, last use and request count, so the one consuming your budget is easy to find.

​
Use a token

Send it as a bearer header on every request.
The path matters. /api/backend/* on the web origin is the same proxy the browser uses, and it forwards the bearer header to the API. When your script runs on the same host as the API, you can call the API directly instead.

​
Revoke a token

Delete it from the same card. Revocation is immediate: the next request carrying that token fails authentication. Changing your password, or recovering a forgotten one, revokes every token the account holds at once. Mint the tokens you still need again afterwards. Rate limits count per workspace rather than per token, so a second token adds no capacity and revoking one does not free any. See Rate limits and quotas. Revoke rather than rotate AUTH_SECRET when a single token leaks. Rotating the secret signs out every browser session and does not affect tokens at all, because tokens are hashes rather than signed values.

​
What a token cannot do

A token, whatever its scope, cannot manage credentials or the workspace itself. These routes need a signed in browser session and answer a token with 403 and the message This needs a signed in session. A personal API token cannot do it. This is what stops a leaked token from minting its own successor. After revoking a leaked write token, also review the webhooks and email alerts it could have added. A token that could mint another token would survive its own revocation and its own expiry. To rotate a token, create the new one in Integrations and then revoke the old one. Listing tokens and reading the team stay open to a token.

​
Where tokens are used

A write scoped personal API token carries the access of the account that created it, including owner access to the admin surfaces when the owner created it, except for the routes that need a signed in session. Never commit one, never paste one into an issue, and give each consumer its own token so a single revocation is enough. Do not reuse a script’s write token for an agent: mint a new one named after the agent, so revoking it ends the agent’s access and nothing else.

Authentication and accounts

How a request is authenticated and authorized.

The queue dashboard and the OpenAPI surface

What an owner token unlocks.
Last modified on October 24, 2026