Skip to main content

Authentication

BrowserBee API requests use token-based authentication. Every production-quality integration should treat tokens as sensitive credentials, isolate them by environment, and rotate them deliberately.

Authentication model​

BrowserBee requests are typically authenticated with a Bearer token in the Authorization header:

Authorization: Bearer <YOUR_TOKEN>

This model works well for:

  • local development
  • CI and deployment automation
  • backend services
  • scheduled jobs and workers

Create a token​

Use the BrowserBee app:

  1. Go to Settings -> API Tokens on app.browserbee.com.
  2. Create a token for the specific application, service, or environment.
  3. Save it securely as soon as it is shown.
  4. Record where that token will be used and who owns it operationally.

Send authenticated requests​

Use the token as a Bearer token on every API request:

curl \
  --header "Authorization: Bearer <YOUR_TOKEN>" \
  --header "Accept: application/json" \
  https://api.browserbee.com/api/v1/browsers

Use these defaults unless you have a strong reason not to:

  • create separate tokens for development, staging, and production
  • create separate tokens for separate services or jobs
  • name tokens so you can revoke them without guesswork
  • avoid sharing one long-lived token across multiple systems
  • store tokens in a secret manager or CI secret store

Storage guidance​

Prefer this order of storage options:

  1. managed secret stores in your cloud platform
  2. CI/CD secret managers
  3. local developer .env files for short-lived local work only

Do not:

  • commit tokens to Git
  • place tokens in client-side JavaScript
  • paste tokens into screenshots, tickets, or chat history
  • reuse production tokens in lower environments

Rotation and revocation​

Rotate tokens whenever:

  • a workload changes ownership
  • a token may have been exposed
  • a team member no longer needs access
  • you are performing routine credential hygiene

When rotating:

  1. create a replacement token
  2. update all dependent systems
  3. verify requests succeed with the replacement
  4. revoke the old token

Troubleshooting authentication failures​

If BrowserBee rejects a request:

  • verify the token was copied completely

  • verify the token belongs to the intended environment

  • verify the Authorization header is present and formatted as Bearer

  • verify the token has not been revoked

  • verify your request is reaching the correct BrowserBee base URL

  • rotate tokens regularly

  • use one token per environment/workload

  • revoke tokens immediately if exposed