Skip to main content

API structure

BrowserBee uses a conventional HTTP resource model. Even when endpoints differ in detail, the overall structure stays consistent enough that you can reuse integration patterns across the API.

Base URL plus resource path​

Every request starts with a base URL and then appends a resource path:

https://api.browserbee.com/api/v1/<resource>

or

https://api-dev.browserbee.com/api/v1/<resource>

Resource collections and individual resources​

The common pattern is:

  • a collection path such as /browsers
  • a single-resource path such as /browsers/\{profile_key\}

That distinction matters because list and single-resource operations usually serve different needs in application code.

Stable identifiers​

When BrowserBee returns an identifier for a resource, your application should treat that value as the canonical way to refer back to the resource later.

Avoid using display labels or presentation-oriented fields when a stable machine identifier exists.

Environment-aware structure​

The same resource paths exist under different environments. That means:

  • the path shape stays familiar
  • your base URL and token carry the environment boundary
  • your application code can often reuse the same request logic across environments

Practical recommendation​

When documenting or implementing BrowserBee requests in your own codebase, always show:

  • the base URL source
  • the auth source
  • the collection or single-resource path
  • any required path or query parameters

That makes examples portable from docs to production code.