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

Provisioning Phases

The progress.current_phase field reports finer-grained progress while status is pending or processing:

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.