Integrate with CI

Integration pattern

#

Most customers integrate BrowserBee at two points in CI:

1. a setup phase that verifies the required profile exists and is in the expected state
2. an operational phase that reacts to BrowserBee changes through webhooks or scheduled syncs

Recommended default

#

Store the BrowserBee token as a pipeline secret and validate access before your test jobs begin.

Example: GitHub Actions

#

name: browserbee-check

on:
  workflow_dispatch:
  pull_request:

jobs:
  verify-browserbee:
    runs-on: ubuntu-latest
    steps:
      - name: Verify BrowserBee profile inventory
        env:
          BROWSERBEE_API_TOKEN: ${{ secrets.BROWSERBEE_API_TOKEN }}
        run: |
          curl --fail --silent --show-error \
            --header "Authorization: Bearer ${BROWSERBEE_API_TOKEN}" \
            "https://api.browserbee.com/api/v1/browsers"          

Good production habits

#

• use a dedicated CI token instead of a shared personal token
• keep token scope aligned to the workflow purpose
• alert on 401 or repeated 422 responses so credential drift is visible
• review deprecated profiles during release planning, not after failures land in pipeline logs

When to add webhooks

#

CI-only verification is enough when your profile inventory changes rarely. Add webhooks when:

• profile changes should trigger environment updates
• you need to notify release or QA systems automatically
• deprecations must create work for downstream teams without manual triage