Set a maximum number of browser jobs, queue excess work, and stop each session when its job finishes. Your account limit applies across all processes using the account.
Check available capacity
Example response for an account with a browser limit:
available is a snapshot. It does not reserve slots; another worker can start a browser before your next request. Set an application concurrency limit below the account cap if other jobs share the account, and handle parallel_browsers_limit_reached at startup.
When has_browser_limits is false, parallel_browsers is null and available is omitted. Browser slots are one of several account limits; limits covers request rates and proxy traffic quotas and the 429 codes each one returns.
Use an SDK pool
The Python and TypeScript SDKs provide map() and browser pools with a concurrency setting and managed cleanup.
A pool can reuse a browser for several items. Cookies, storage, and open pages can carry over. Use separate sessions for jobs that need independent state, and retire a browser after a job that leaves it unusable.
A persistent profile represents one running browser at a time. Starting an already running profile can return that session. Use different profiles to run different accounts concurrently.
Stop sessions after failures
Put the stop call in finally, outside the framework connection block, so it also runs if connecting fails. The framework quickstarts show the full lifecycle.
The idle timeout closes a browser after a period without activity. Choose a timeout long enough for legitimate pauses, but avoid using it as the only cleanup mechanism. See session lifetime.
After a worker crashes, compare GET /profiles/active with the session IDs your application owns. Session age alone does not prove a leak: another worker may still be using that browser. Stop only sessions you can identify as abandoned.
POST /profiles/stop stops every browser on the account, including work owned by other processes. Use individual stop calls for routine cleanup.
Increase load gradually
Start with a small worker count. Measure completed jobs, target-site failures, proxy traffic, and browser startup errors before raising it.
Browser slots and API rate limits are separate. Starting many browsers at once can hit a request limit even when slots remain. Queue startups and use bounded backoff with jitter for temporary capacity errors. See errors and retries.
A timed-out start has an uncertain outcome: the server may have created a browser before the connection was lost. Check active sessions before blindly repeating one-time start requests.
What to monitor
