↓ Skip to main content
BrowserBee
  1. Documentation/
  2. Guides/

Manage browser profiles

Create, update, activate, deprecate, and remove BrowserBee browser profiles with predictable lifecycle control.

Typical profile workflow
#

Most teams follow a simple lifecycle:

  1. create a profile
  2. validate it in limited automation
  3. activate it for broader use
  4. deprecate it before retirement
  5. delete it when no longer needed

Create a profile
#

curl --request POST "https://api.browserbee.com/api/v1/browsers" \
  --header "Authorization: Bearer ${BROWSERBEE_API_TOKEN}" \
  --header "Content-Type: application/json" \
  --data '{
    "profile_key": "firefox-beta-linux",
    "name": "Firefox Beta on Linux",
    "channel": "beta",
    "version": "137",
    "status": "preview",
    "capabilities": ["webdriver", "video"],
    "platforms": ["linux"],
    "configuration": {
      "timeout_seconds": 120,
      "retry_attempts": 1,
      "headless": true
    }
  }'

Update or replace a profile
#

Use PATCH for incremental updates or PUT when your workflow treats the profile definition as the full source of truth.

curl --request PATCH "https://api.browserbee.com/api/v1/browsers/firefox-beta-linux" \
  --header "Authorization: Bearer ${BROWSERBEE_API_TOKEN}" \
  --header "Content-Type: application/json" \
  --data '{
    "status": "available",
    "version": "137.0.1"
  }'

Activate a profile
#

Activation is useful when a preview profile is ready for broader use:

curl --request POST "https://api.browserbee.com/api/v1/browsers/firefox-beta-linux/activate" \
  --header "Authorization: Bearer ${BROWSERBEE_API_TOKEN}"

Deprecate a profile
#

Deprecation helps downstream teams migrate before removal:

curl --request POST "https://api.browserbee.com/api/v1/browsers/firefox-beta-linux/deprecate" \
  --header "Authorization: Bearer ${BROWSERBEE_API_TOKEN}"

Delete a profile
#

Delete only after all dependent automation has moved away from the key:

curl --request DELETE "https://api.browserbee.com/api/v1/browsers/firefox-beta-linux" \
  --header "Authorization: Bearer ${BROWSERBEE_API_TOKEN}"

Recommended rollout pattern#

For customer environments, a strong default is:

  • create new versions as preview
  • validate in a limited pipeline
  • promote to available
  • mark the old profile deprecated
  • remove only after the last consuming workflow is updated

That sequence keeps your profile catalog predictable and lowers change risk.