Go to platform

Personal Access Tokens

A personal access token is your own credential: a long-lived key tied to your A vs B account. It authenticates the CLI when you run avsb login, and it can call the API on your behalf. Unlike a browser session it needs no browser, which is what makes it the right credential for developer tooling.

It is one of four A vs B credentials. Credentials is the map of all four, and which one to reach for.

What tokens are for

  • CLI authentication: the avsb command line tool authenticates with a personal access token. When you run avsb login, you are asked to paste one. This is the main use.
  • Direct API access: pass the token as a Bearer token to call the public API as yourself, for a personal script or a one-off query.
For CI, use a service token instead

A personal access token acts as you, so it carries your whole account's reach and stops working the day your access changes. For CI pipelines, Terraform, and other automation, create a service token in Organization Settings and give it exactly the scopes that job needs.

Token format

Every personal access token is the prefix avsb_pat_ followed by a 64-character hexadecimal string:

Plain text
avsb_pat_a3f8c2d1e5b9f04712c8a6e3d0b7f29e1a4c5d8f3e2b1a0c9d7f6e5b4a3c2d19
Plain text1 line

The prefix makes tokens easy to spot in a code review, easy to grep for, and recognisable to secret-scanning tools. Service tokens use avsb_svc_ for the same reason.

Creating a token

1

Open Account Settings

Click your account avatar or name in the top-right corner of the A vs B dashboard. Select Account from the dropdown menu. This opens the Account Settings page.

2

Go to the Personal Access Tokens tab

Inside Account Settings, click the Personal Access Tokens tab. You will see any tokens you already have, and a button to create another. You need the Owner, Admin, or Developer role in the organization to see this tab.

3

Click Create token

Click the Create token button. A dialog asks you to name the token.

4

Enter a name

Name it after where it will live: Laptop CLI, CI pipeline, Home dev machine. The name has no effect on what the token can do; it is how you know which one to revoke later.

5

Copy the token immediately

The token value is displayed once and only once. Copy it somewhere safe; a password manager is ideal. Once you close the dialog, A vs B will never show it again. If you lose it, revoke the token and create a new one.

Copy the token now: it is only shown once

A vs B stores only a hashed version of your token. The plain-text value exists at creation time and nowhere else. There is no "reveal token" option afterwards.

What a personal access token can do

The token carries your own authority, and only yours:

  • Reading follows what the dashboard shows you. If you can see it in the UI, the token can read it.
  • Writing follows your role. If your role lets you author flags, experiments, or metrics in the dashboard, the token can author them through the API.
  • Token management is never included. A token can never create, rotate, or revoke tokens, and never carries organization-wide admin authority. That is deliberate: a leaked token must not be able to mint more.
Scopes are resource-level, not environment-level

Scopes name a resource family (flags:write), not an environment. A role that can author flags but must not publish to production can still change a production flag through the API with its token. Where a job must be tightly bounded, use a service token with exactly the scopes it needs.

Token limits

Each account can have a maximum of 10 active tokens at a time. If you have reached the limit, revoke one before creating another.

Using a token in the CLI

Run avsb login in your terminal. The CLI asks you to paste your personal access token, and masks it as you type:

Shell
$ avsb loginPaste your personal access token: ********Token verifiedLogged in to Acme Corp as jane@example.comToken saved in plain text at /Users/jane/.avsb/config.json (file mode 0600).
Shell5 lines

You will not need to paste it again unless you log out or revoke the token.

The saved token is plain text, not a keychain entry

avsb login writes ~/.avsb/config.json and sets the file mode to 0600, so only your user account can read it on macOS and Linux (Windows ignores mode bits). The file itself is plain-text JSON on every operating system: no macOS Keychain, no Windows Credential Manager, no encryption. Anything running as your user can read the token, so treat the file like a password and do not copy it between machines.

On a shared machine, in a container, or in CI, set the AVSB_TOKEN environment variable instead of logging in. Every command uses it, nothing is written to disk, and it takes priority over a saved login. See CLI Authentication for the full precedence rules.

Using a token in API requests

Pass the token as a Bearer token. /api/v1 accepts personal access tokens alongside service tokens, so the same routes serve both:

Shell
curl https://app.avsb.cloud/api/v1/projects \  -H "Authorization: Bearer avsb_pat_a3f8c2d1e5b9f04712c8a6e3d0b7f29e1a4c5d8f3e2b1a0c9d7f6e5b4a3c2d19"
Shell2 lines

That returns the projects your account can see. Everything else hangs off a project, addressed by the numeric project ID the dashboard shows:

Shell
curl https://app.avsb.cloud/api/v1/projects/42/experiments \  -H "Authorization: Bearer avsb_pat_..."
Shell2 lines

A token that has been revoked or has expired fails with 401 and an error code that says which. See Public API Authentication for the response envelope, error codes, and rate limits.

Last used timestamp

Each row in the Personal Access Tokens tab shows a last used timestamp: when that token most recently made an authenticated request. It is the quickest way to tell which tokens are still doing something and which can go.

Revoking tokens

To revoke a token, go to Account Settings → Personal Access Tokens and click Revoke next to it. The token stops authenticating immediately; any CLI session or script using it starts failing on its next call.

There is no undo. If you revoke the token your CLI is using, create a new one and run avsb login again.

Never share tokens or commit them to version control

A personal access token acts as you, with your permissions, in every organization you belong to. Treat it like a password:

  • Never paste it into Slack, email, or a shared document.
  • Never commit it to a Git repository, even a private one. Use environment variables for any automation.
  • Never share it with teammates; each person creates their own.

If you suspect a token has been compromised, revoke it immediately and create a new one.

Was this helpful?