Manage API tokens

The default mistake in new integrations is reusing one BrowserBee token everywhere. A better default is a small token plan that matches your environments and workloads.

Recommended default token layout

Environment	Suggested token owner	Example token name
Local development	individual developer	local-dev-alex
Shared development	shared non-production service	dev-api-worker
Staging	staging automation or preview app	staging-browser-sync
Production	production workload only	prod-browser-sync

This model makes audit, rotation, and incident response easier.

Step 1: Create separate tokens per environment

Create at least:

• one development token
• one production token

If you have CI, previews, or staging, create separate tokens for those as well.

Step 2: Store tokens where they belong

Use these defaults:

1. local work: .env files ignored by Git
2. CI and deployments: repository or environment secrets
3. cloud workloads: managed secret stores

The important rule is that BrowserBee tokens should never end up in committed source code or client-side bundles.

Step 3: Make ownership explicit

Each token should have:

• a clear owner
• a clear workload
• a known environment
• a documented rotation process

If no one knows what would break when a token is revoked, the token is not managed well enough.

Step 4: Rotate deliberately

When rotating a token:

1. create the replacement
2. deploy the replacement
3. confirm requests succeed
4. revoke the previous token

This avoids service disruption and makes rollback simpler.

Step 5: Prepare for exposure events

If a token may have been exposed:

• revoke it quickly
• replace it with a new token
• review logs and downstream systems
• document the event so the next response is faster

Next steps

• Review Authentication.
• Review Prepare multiple environments.