Skip to main content

API limits

Even if a single endpoint call looks simple, production integrations should always assume the platform may enforce throughput, concurrency, or operational limits.

Why limits matter​

Limits protect both BrowserBee and your integration from unstable behavior during:

  • bursts of background synchronization
  • fan-out jobs
  • repeated retries
  • multi-tenant or multi-workspace workloads

Good default behavior​

Use these defaults in early integrations:

  • avoid unnecessary polling
  • cap concurrency
  • back off when requests fail transiently
  • queue or batch work on your side when volume grows

How to think about throughput​

Instead of asking only "how fast can we call BrowserBee?", ask:

  • how many requests do we actually need?
  • which ones can be delayed safely?
  • which ones can be grouped or deduplicated?
  • which workflows should degrade gracefully under pressure?

That mindset usually matters more than any single numeric limit.

Signals to watch​

Your application should monitor:

  • request volume
  • error rate
  • retry rate
  • latency
  • sustained backoff behavior

Those signals help you distinguish normal traffic from integration stress.

Next steps​