Three independent limits apply, and you hit whichever comes first: concurrency caps how many sessions you may have open at once, the monthly allowance caps actions, browser hours, and egress per calendar month, and rate limits cap requests per minute to protect the service.

Plans

Enterprise plans lift every cap; contact us. An action is a fetch that returned content. Blocked or failed attempts are not counted against you. Usage and credits covers checking where you stand against these limits with GET /v1/usage.

Concurrency

Concurrency counts live sessions, not requests. Exceeding it returns:
The cap is enforced across your whole account, not per client or per region. The usual cause of an unexpected 429 is sessions that were never released, so check GET /v1/sessions. Release sessions in a finally block:

Rate limits

Separate from plan quotas and applied per account: Exceeding a rate limit returns 429. Back off exponentially.

Credits

Metered usage past the allowance draws on a credit balance, and an empty wallet returns 402 with the machine-readable code insufficient_credits. Usage and credits covers checking the balance and redeeming codes.

Handling limits well

  • Read remaining from /v1/usage rather than waiting for a 402.
  • Cap your own concurrency below the plan limit so a burst does not lock out your other jobs.
  • Keep idle_timeout short, because browser hours accrue for as long as a session exists, whether or not you are driving it.
  • Retry 429 with backoff, never in a tight loop.