Skip to main content
A pool keeps browsers running with the options you chose. Acquire hands you one in under a second as an ordinary session, and the pool warms a replacement. Use one when start-up latency matters (an agent loop, a request handler, a burst of short jobs) or when every job wants the same start page, profile or country. A nightly batch that can wait a few seconds per browser is fine with plain create. Pools are also in the dashboard under Browsers → Browser pools; Launch browser on the Overview can take one from any ready pool.

Create a pool

Answers 201 at once with the pool warming; measured, it was ready two to five seconds later.

Fields

Unknown fields, top-level or inside browser, are a 400 (bogus is not supported by this endpoint), and so is a country the platform doesn’t serve (Unsupported country "ZZ"). Pool responses echo the template with what the platform resolved for it (timezone, and a proxyUrl with the credentials redacted). lastError is set when browsers fail to start. profile works as on a session. Leave persist off (the default) so every browser loads it read-only; several browsers writing one profile would overwrite each other.

Status and counters

ready, starting and leased count browsers in each state. Ready browsers aren’t sessions yet: GET /v1/browser/sessions doesn’t list them and they hold no concurrency slot until acquired.

Acquire a browser

waitMs (0 to 30000, default 0) is how long to wait when nothing is ready; a replacement warms in two to three seconds, so a few seconds is enough. The body is required: {} for no wait (no body is a 400 Malformed JSON in request body). Nothing ready in time: 409 No browser is currently ready in this pool. Paused pool: 409 Pool is paused at once. Treat the first like a create 503: back off, cap, then fall back to a plain create or report. From here session is an ordinary session: listed, readable with GET /v1/browser/session?sessionId=…, counted as a running browser, watchable in the live view. createdAt is when the browser was warmed, not when you acquired it, and the page is already on the pool’s url. Connect with Patchright as usual:
acquire and release are the two calls on this page; the reference client has both.

Release or stop

A leased browser ends one of three ways; the pool warms a replacement each time.
  • Release: POST /v1/browser/pools/{poolId}/release with { "leaseId": "…" }. Stops the session; answers { "poolId", "leaseId", "sessionId", "status": "ended", "returnedAt" }. Do it in a finally.
  • Stop it with DELETE /v1/browser/session?sessionId=…. Same effect; the lease closes within a few seconds.
  • Let the lease expire. At expiresAt (leaseTimeoutSeconds after acquire) the session is stopped whether or not you’re done. Pick a lease that covers the job.
Release ends billing, like a stop. It’s idempotent (same body twice); an unknown lease, or one from another pool, is 404 Pool lease not found. A browser is never handed back for another job; the next acquire gets a fresh one.

Manage a pool

Pool ids go in the path. Session ids go in the query string.

Errors

Cost and limits

Warm browsers aren’t sessions: not listed, not billed, no concurrency slot. Acquired, a browser is a session like any other: it counts toward the concurrency limit and its bandwidth is metered until release, stop or lease expiry. The 30-warm cap per account is separate from the concurrency limit.

Next

  • Lifecycle: what you can do with the acquired session.
  • Create a session: every option the browser template accepts.
  • For agents: the reference client has acquireFromPool and releaseLease.