Sessions

Each browser run is a Session, controlled through our APIs.

Overview

In web automation, a browser session in web automation represents a single browser instance, from connection to termination: closure, timeout, or disconnection, running in isolated environments to ensure resource exclusivity, thereby maintaining stability and performance.

These sessions are highly configurable through APIs, allowing for adjustments to settings such as running in a selected geographic region or specifying a keep alive session.

Sessions also support on-the-fly file downloads and can be easily started with automation frameworks like Playwright, Puppeteer, or Selenium, or pre-configured using a Session API, offering flexibility and control for developers.

Browser configuration

Sessions run on fast instances with isolated resources (storage, network, memory, and vCPUs).

The viewport, user agents, and header configuration are handled by the fingerprint mechanism.

Downloads are enabled and stored by default, accessible via the API.

Sessions

Starting a Session

A Session is either created implicitly upon connection (via connectOverCDP() or puppeteer.connect()), or via the Sessions API.

Once created, connect to a Session through a Driver (Playwright, Puppeteer, or Selenium) or via the Session Inspector.

• Node.js
• Python

You must connect to a Session within the timeout supplied during creation or the default timeout of your project.

Asynchronous Sessions

You can also create and manage Sessions asynchronously. This is useful if you want to run your automation in an asynchronous environment, such as an asyncio event loop.

Here’s an example using Playwright with async/await:

• Python

Playwright

import os
from playwright.async_api import async_playwright, Page
import asyncio

# Use environment variable for API key

API_KEY = os.environ.get("BROWSERBASE_API_KEY")

async def run(browser_tab: Page):
    await browser_tab.goto("https://www.sfmoma.org")
    await browser_tab.get_by_role("link", name="Tickets").click()
    print(f"Current URL: {browser_tab.url} | Page title: {await browser_tab.title()}")

async def main():
    async with async_playwright() as playwright:
        browser = await playwright.chromium.connect_over_cdp(
            f"wss://connect.browserbase.com?apiKey={API_KEY}"
        )
        print(
            f"Connected to Browserbase. {browser.browser_type.name} version {browser.version}"
        )
        context = browser.contexts[0]
        browser_tab = context.pages[0]
        await run(browser_tab)

if __name__ == "__main__":
    asyncio.run(main())

Session Timeout

Sessions time out when running for longer than the timeout configured in your Project’s Settings:

The following code samples require the Browserbase SDK.

To keep sessions alive upon disconnections, provide the keepAlive param when creating a new Session and stop the session manually:

• Node.js
• Python

import Browserbase from "browserbase";

const BROWSERBASE_API_KEY = process.env.BROWSERBASE_API_KEY!;
const BROWSERBASE_PROJECT_ID = process.env.BROWSERBASE_PROJECT_ID!;

// Initialize the SDK
const bb = new Browserbase(BROWSERBASE_API_KEY);

// Create a session with `keepAlive` set to `true`
const session = await bb.sessions.create({
  projectId: BROWSERBASE_PROJECT_ID,
  keepAlive: true,
});

// Terminate the session
await bb.sessions.update(session.id, {
  projectId: BROWSERBASE_PROJECT_ID,
  status: "REQUEST_RELEASE",
});

For more information on using keep alive sessions, please refer to our Long Running Sessions guide.

We recommend that you release your keep alive sessions manually when no longer needed. They will time out eventually, but you may be charged for the unneeded browser minutes used.

Inspecting a Session

You can inspect a completed Session using the Session API or the Session Inspector:

Action	Session Inspector	Sessions API
Access logs	✅	Sessions API logs endpoint
Access ChromeDevTools data (ex: network, DOM events)	✅	Sessions API logs endpoint
Access recording	✅	Sessions API recording endpoint
Retrieve downloaded files	❌	Sessions API downloads endpoint
Session Live View	❌	Sessions API Live URLs endpoint
Access memory and CPUs usage	✅	❌

Session Concurrency and Rate Limiting

When reaching the session concurrency limit of your plan, any subsequent request to create a new session will return an HTTP 429 error. That means the request was effectively dropped.

You can create sessions again by running fewer concurrent sessions or by closing them explicitly when no longer needed rather than letting them time out.

If you need more concurrency, you can upgrade to a plan that allows for a higher limit. For example, the Hobby plan allows for 3 concurrent browsers while the Startup plan increases the limit to 50. The Scale plan gives you as many concurrent sessions as you need.

Since each browser session runs for 1 minute minimum, this also means that you cannot create more than your plan’s session limit within a 60 second window.

There no rate limits for calls during a session; they apply only at session create time.