Skip to main content

Common workflows

Most BrowserBee teams do not need a custom onboarding path. The defaults below are sensible starting points for the majority of integrations.

New integration workflow​

Use this when you are connecting BrowserBee to a new internal tool, backend service, or automation worker.

  1. Create a development token.
  2. Verify connectivity with GET /browsers.
  3. Read one resource-specific endpoint such as GET /browsers/\{profile_key\}.
  4. Decide whether you will keep using raw HTTP or switch to generated clients.
  5. Add retry logic and structured error handling before promoting to production.

Local development workflow​

Use this when an engineer needs to experiment quickly without affecting production credentials.

  1. Use the development base URL.
  2. Store a short-lived local token in a non-committed .env file.
  3. Make exploratory requests from curl or an API client.
  4. Capture successful request patterns in shared docs or client code.
  5. Replace personal tokens with service-owned tokens before merging automation.

Production readiness workflow​

Use this before routing live workloads through BrowserBee.

  1. Create a dedicated production token for the target workload.
  2. Confirm the same request flow succeeds in production with production-safe data.
  3. Add observability around request failures and retries.
  4. Document token ownership, rotation, and revocation procedures.
  5. Keep the API Reference open during rollout for fast endpoint verification.

Event-driven workflow​

Use this when BrowserBee should notify your systems rather than requiring constant polling.

  1. Model the event contract you need internally.
  2. Configure webhook delivery and receiving endpoints.
  3. Verify signature, source, and idempotency rules on your side.
  4. Separate delivery failures from business-logic failures in your handler.
  5. Monitor redelivery, latency, and dead-letter handling as volume grows.

Choosing the next section​