Skip to main content

Create your first browser profile

Once GET /browsers is working, the next useful milestone is understanding how your integration will address and operate on a specific browser profile.

What this guide is for​

Use this guide when you want to:

  • verify that profile-oriented paths work in your environment
  • move beyond connectivity checks into resource-specific handling
  • design your application code around a real BrowserBee resource

Step 1: Start from a known-good authenticated request​

Before you do anything profile-specific, make sure:

  • your token works
  • your base URL is correct
  • your integration is receiving JSON responses successfully

If you have not done that yet, complete Quick Start first.

Step 2: List available browser profiles​

The most reliable first resource call is a list request:

curl --silent \
  --request GET \
  --header "Authorization: Bearer ${BROWSERBEE_API_TOKEN}" \
  --header "Accept: application/json" \
  "${BROWSERBEE_BASE_URL}/browsers"

This step tells you how BrowserBee represents browser profiles in your environment and what identifiers you should persist in your own application.

Step 3: Capture the profile identifier you will use​

Your application should store the stable identifier BrowserBee returns for a profile. In the docs this is represented as profile_key.

That identifier is what powers resource-specific requests such as:

GET /browsers/\{profile_key\}

Step 4: Read a single profile​

Once you have a profile identifier, make a resource-specific request:

curl --silent \
  --request GET \
  --header "Authorization: Bearer ${BROWSERBEE_API_TOKEN}" \
  --header "Accept: application/json" \
  "${BROWSERBEE_BASE_URL}/browsers/<PROFILE_KEY>"

This step proves that your application can:

  • interpolate path parameters correctly
  • retrieve one known resource reliably
  • distinguish list operations from resource operations

Step 5: Model the profile in your code​

At this point decide what your code needs to preserve from the response:

  • BrowserBee identifier
  • status or lifecycle fields
  • ownership or mapping fields in your application
  • timestamps and operational metadata

Avoid persisting the entire raw response blindly. Prefer an internal model that stores the BrowserBee fields your application truly depends on.

Step 6: Decide how profile operations will be organized​

The sensible default is:

  1. list profiles for discovery and audits
  2. read one profile by key for targeted operations
  3. use the API Reference for create, update, or delete operations your workflow needs

This keeps the application model simple and predictable.

Common pitfalls​

  • using the wrong environment for the token you created
  • treating display labels as stable identifiers
  • skipping single-resource reads and going directly into automation
  • assuming every application needs to mirror every BrowserBee field

Next steps​