Authentication modes#
BrowserBee currently uses two authentication patterns:
| Use case | Authentication mode | Endpoint examples |
|---|---|---|
| Create an API token | HTTP Basic | POST /tokens |
| Normal API operations | Bearer token | /browsers, /tokens/{id}, /webhooks |
Creating tokens with Basic auth#
Use your BrowserBee account email and password when creating a new token:
curl --request POST "https://api.browserbee.com/api/v1/tokens" \
--user "you@example.com:YOUR_PASSWORD" \
--header "Content-Type: application/json" \
--data '{"token":{"name":"ci-runner"}}'Basic auth is intentionally limited to token creation. Do not build automation that relies on your account password after onboarding.
Calling the API with Bearer auth#
Pass the token as an Authorization header:
curl --request GET "https://api.browserbee.com/api/v1/browsers" \
--header "Authorization: Bearer ${BROWSERBEE_API_TOKEN}"Recommended storage defaults#
For customer deployments, the safest defaults are:
- store BrowserBee tokens in your secrets manager, not in source control
- issue separate tokens for humans, CI, and automation receivers
- name tokens after their purpose so revocation is low risk
- revoke tokens that are no longer mapped to an active workflow
Common authentication failures#
401 unauthorized#
BrowserBee returns 401 when credentials are missing, malformed, or invalid.
Check:
- you used Basic auth only for
POST /tokens - the Bearer token value is complete and not truncated
- your client is targeting the correct environment
Token was shown once and lost#
The plaintext token is returned once by design. Revoke the original token if necessary and create a replacement with a new name so audit and ownership stay clear.