Skip to main content

SDKs

SDKs are a strong fit when your BrowserBee integration grows beyond initial exploration and needs typed contracts, shared request handling, or code reuse across services.

When to use an SDK​

Prefer an SDK or generated client when:

  • more than one service calls BrowserBee
  • you want typed request and response models
  • you want to centralize auth, retries, and request construction
  • you want to regenerate code from the API contract as BrowserBee evolves

Language strategy​

The BrowserBee documentation is designed to support:

  • browserbee-node
  • browserbee-python
  • browserbee-ruby
  • browserbee-go

These names are useful targets for generated clients or curated wrappers, even if your first production integration begins with raw HTTP.

  1. Start with curl or a simple HTTP client while discovering the API.
  2. Move to a generated client when the integration needs to be shared or stabilized.
  3. Wrap the generated client in your own BrowserBee service layer so application code does not need to know request details everywhere.

What your wrapper should own​

The best BrowserBee client wrappers usually centralize:

  • environment selection
  • token injection
  • default headers
  • retries and backoff
  • logging and tracing
  • request timeout defaults

Relationship to OpenAPI​

If you want typed SDKs or client generation, the OpenAPI documentation is the next page to read. The OpenAPI contract is what lets BrowserBee integrations stay consistent across languages and tools.

Recommendations​

  • pin SDK versions in production
  • align SDK version with API changelog
  • use sandbox/test credentials for integration tests first