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
POST /v1/sessions is also accepted here.
A successful response is returned immediately:
Poll for Readiness
Poll the status endpoint using therequest_id until status becomes ready.
session object is populated:
Request Statuses
Provisioning Phases
Theprogress.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. SetANCHOR_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.
