Skip to main content

Integrate with generated clients

BrowserBee supports a simple progression:

  1. explore the API with curl or an API client
  2. validate your first request path
  3. move to generated or wrapped clients when the integration becomes shared or long-lived

When raw HTTP is enough​

Prefer raw HTTP when:

  • you are still exploring the API
  • the integration is a one-off script
  • you want maximum transparency into request and response details

When a generated client is better​

Prefer generated or wrapped clients when:

  • multiple services call BrowserBee
  • you want typed request and response models
  • you need shared retry, auth, and error handling behavior
  • you want to regenerate code from the OpenAPI contract as the API evolves

The practical default for most teams is:

  1. start with curl during discovery
  2. move to a generated client for production code
  3. wrap that client with BrowserBee-specific helpers inside your own codebase

That gives you both contract alignment and application-specific ergonomics.

What to centralize in your wrapper​

If you build a BrowserBee client wrapper, centralize:

  • base URL selection
  • token injection
  • default headers
  • retry policy
  • logging and tracing
  • response normalization where needed

This keeps endpoint code focused on business logic instead of request plumbing.

Where the OpenAPI spec fits​

The BrowserBee OpenAPI contract is the best foundation for:

  • client generation
  • schema-aware tooling
  • endpoint discovery
  • request and response validation in tests

See OpenAPI for the recommended workflow.

Next steps​