Skip to main content
BeaconLife Sciences

Rate limits

Every API client is rate limited — 600 requests per 10-minute window. The API tells you where you stand with RateLimit-* headers on every response.

The limit

Each API client may make up to 600 requests per 10-minute window. The window is per client — not per organization and not per IP — so two clients issued to the same organization have independent budgets, and the budget applies across all endpoints including the token endpoint.

600 requests per 10 minutes is one request per second on average. For integrations that synchronize overnight or on a schedule that is ample; for always-on pipelines, use conditional requests (ETag) and webhooks instead of polling, so the budget goes to the calls that matter.

RateLimit-* response headers

Every API response carries headers describing the current state of your budget:

Rate limit response headers
HeaderMeaning
RateLimit-LimitThe request budget for the current window (600).
RateLimit-RemainingHow many requests are left in the current window.
RateLimit-ResetWhen the current window resets (a timestamp).
RateLimit-Limit: 600
RateLimit-Remaining: 57
RateLimit-Reset: 1768986000

Read RateLimit-Remaining and slow down before you hit the wall — the header exists so you never have to discover the limit by failing.

429 Too Many Requests

Exceed the budget and the API responds 429 with a problem+json body (see errors). The response includes a Retry-After header giving the number of seconds to wait before the next attempt. Honor it — requests made before Retry-After elapses will keep being rejected and can extend the throttling.

HTTP/1.1 429 Too Many Requests
Retry-After: 42
Content-Type: application/problem+json

Back off for the full Retry-After interval, and add jitter so many workers do not all fire at the same instant when the window resets.

Design guidance

  • Read RateLimit-Remaining on every response and throttle proactively instead of reacting to 429s.
  • Use conditional requests where the API supports them (see pagination) so unchanged reads stay cheap.
  • Subscribe to webhooks (see webhooks) instead of polling for changes.
  • Smooth bursts where you can; a steady trickle is safer than a burst against a rolling window.
  • If a legitimate integration needs more than 600 requests / 10 min, contact the platform team to discuss the workload rather than hammering the limit.