Credentials

A vs B has four credentials and no others. Each one has a single name, a single home in the dashboard, and a fixed shape you can recognise on sight. This page is the map. Every other page links here rather than repeating it.

Credential	Looks like	Where it lives	Acts as	Public?
Personal access token	`avsb_pat_` + 64 hex characters	Account Settings → Personal Access Tokens	You	No. Treat it like your password
Service token	`avsb_svc_` + a long random string	Organization Settings → Service Tokens	The organization	No. Treat it like a password
SDK key	`sdk_<environment>_<id>`, for example `sdk_production_xxxxxxxxxxxxxxxx`	Feature flag project → Environments	One environment, read only	Yes. Ships in your app
Snippet key	a long random id with no prefix, for example `clx7p2m9k0001s8fh2a1b3c4d`	Project Settings → Snippet	One web experiments project, read only	Yes. Ships in your page

The split is the thing to remember: the two tokens manage your account and your data, so they are secrets. The two keys only read one project's published configuration and send events, so they are not.

Personal access token

Your own credential. It is what the avsb command line tool authenticates with, and what a personal script should use.

Create it: Account Settings → Personal Access Tokens → Create token. The value is shown once.
Use it: avsb login (or the AVSB_TOKEN environment variable), and as a Bearer token on the public API.
What it can do: whatever your role in that organization lets you do, and nothing more. Reading follows what the dashboard shows you.

Writing follows the same capabilities that let you author things in the dashboard.
What it can never do: create, rotate, or revoke tokens, and it never carries organization-wide admin authority. Token management is a dashboard-only action on purpose, so one leaked token cannot mint more.
Limit: 10 active tokens per account. Revoke one to make room.

Full walkthrough: Personal Access Tokens. CLI specifics, including the headless path for CI: CLI Authentication.

A scope is a named permission on a token, like flags:write, that controls what it can read or change. It is not environment-level: there is no flags:write in staging only. So a role that can author flags but must not publish to production can still change a production flag through the API.

For automation that should be tightly bounded, create a service token with exactly the scopes it needs, and keep personal tokens for your own machine.

Service token

The organization's credential, for CI, infrastructure tooling, and anything server-to-server. It belongs to the organization rather than to a person, so it keeps working after that person changes role or leaves.

Create it: Organization Settings → Service Tokens → Create token. You choose its scopes, and can set an expiry. The value is shown once.
Use it: Bearer token on /api/v1. Server-side only: /api/v1 sends no CORS headers, so a browser cannot call it.
What it can do: exactly the scopes you ticked, on that one organization.

Scope list, rotation, revocation and error codes: Public API Authentication.

SDK key

The public identifier a feature flag SDK uses to fetch its configuration. A feature flag is a setting in your code that you can turn on, off, or change without a new deploy. There is one key per environment, and the same key serves browser, mobile, and server SDKs. There is no separate client key or server key.

Your SDK key is a public identifier, not a secret: it is safe to ship in browser and mobile bundles, it can only fetch that environment's flag configuration and send events, and it can never read or change anything in your dashboard. Credentials covers all four A vs B credentials and which one to reach for.

Find it: Environments in your feature flag project's sidebar. It's a top-level item, not under Settings, and web experiments projects don't have it. Each environment card shows its key.
Shape: sdk_ then the environment key, then a random id. Default environments give you sdk_production_… and sdk_development_…. Your own environments use their own key, so an environment keyed staging produces sdk_staging_….
What it can do: fetch that environment's published flag configuration from the CDN, and send events and exposures back.
What it cannot do: read or write anything in the dashboard, see other environments, or reach the management API.
Rotate it: keys are per environment. To retire one, create a new environment, move traffic to it, then archive the old one.

Anyone who reads your app's bundle can read the key, and with it your published flag rules for that environment. That is inherent to client-side evaluation, not specific to A vs B. Keep genuinely sensitive logic on the server instead, where a server SDK or the edge SDK evaluates it without shipping the rules to the browser.

Install guides: SDK installation.

Snippet key

The public identifier the web experiments snippet uses. One per project, and it appears in the install tag as data-avsb, so it is visible in the page source by design.

Your snippet key is a public identifier, not a secret: it sits in the install tag on every page, it can only fetch that project's experiment configuration and send events, and it can never read or change anything in your dashboard. Credentials covers all four A vs B credentials and which one to reach for.

Find it: Project Settings → Snippet. The generated tags already contain it.
What it can do: fetch that project's published experiment configuration from the CDN, and send exposures and events back.
What it cannot do: read or write anything in the dashboard.

Install guide: Quick install.

Which one do I need?

Running the CLI on your laptop, or a script that acts as you: personal access token.
A CI job, a Terraform-style tool, or a backend service calling /api/v1: service token.
Evaluating feature flags in an app (browser, mobile, server, or edge): SDK key for the target environment.
Running web experiments on a website: snippet key, already in the install tag.

Keeping the secrets secret

The two tokens are the ones worth protecting.

Store them in environment variables or a secret manager, never in source control.
One token per place it runs, named after that place, so you can revoke exactly the right one.
Personal tokens are personal: each teammate creates their own rather than sharing yours.
If you suspect a leak, revoke the token and create a new one. Revoking takes effect immediately.

A vs B stores only a hash of each token, so no screen can show you a token value again after it is created. If you lose one, create a replacement.