Skip to main content
Not sure which approach to use? See Browser Sessions for sync vs async vs batch.

Overview

POST /v1/sessions/async is the non-blocking variant of POST /v1/sessions. Instead of waiting for the underlying browser pod to provision, it returns a request_id immediately and provisions the session in the background. You then poll GET /v1/sessions/async/{request_id}/status until the request reaches the ready status, at which point the response includes the resolved session_id, cdp_url and live_view_url. This pattern is useful when you want to:
  • Kick off many sessions in parallel without holding open long-lived HTTP requests.
  • Avoid request timeouts while large or proxied sessions are being provisioned.
  • Decouple session creation from session consumption (for example, queue the work and connect later).

How It Works

1

Create the async request

Send a POST to /v1/sessions/async with your browser configuration. The response returns immediately with a request_id and status: "pending".
2

Poll for readiness

Call GET /v1/sessions/async/{request_id}/status on an interval. The request moves through the provisioning phases until status becomes ready.
3

Connect to the session

Once ready, read session_id, cdp_url and live_view_url from the embedded session object and connect over CDP as you would for a standard session.

Create an Async Session

The request body is identical to the standard Start Browser Session request, so any configuration you can pass to POST /v1/sessions is also accepted here. A successful response is returned immediately:

Poll for Readiness

Poll the status endpoint using the request_id until status becomes ready.
A response while provisioning looks like:
Once ready, the embedded session object is populated:

Request Statuses

StatusDescription
pendingRequest accepted, not yet picked up for provisioning.
processingThe browser pod is being provisioned and configured.
readyThe session is connectable. session.session_id, cdp_url and live_view_url are available.
completedThe session has finished its lifecycle.
failedProvisioning failed. No session was produced.
cancelledThe request was cancelled before a session was produced.

Provisioning Phases

The progress.current_phase field reports finer-grained progress while status is pending or processing:
PhaseDescription
queuedWaiting for capacity.
provisioningThe browser pod is starting up.
configuringApplying your browser and session configuration.
readyThe session is up and connectable.

Complete Example

The following script spawns multiple async sessions in parallel, polls each one until it is ready, and prints the connection details. Set ANCHOR_API_KEY in your environment before running.
Once a session is ready, connect to it over CDP using the returned cdp_url, exactly as you would for a standard session. The session honors the same idle_timeout and max_duration settings you passed in the configuration, so make sure to connect before the idle timeout elapses.