Browserless

Browserless provides managed headless Chrome instances that agents connect to via WebSocket (Puppeteer/Playwright) or REST API. For agents that need browser automation — scraping dynamic pages, generating PDFs, taking screenshots, testing web applications — Browserless eliminates the need to run and scale browser infrastructure. The WebSocket connection model means existing Puppeteer or Playwright scripts work with a single connection URL change. The REST API provides simpler operations without browser automation libraries: POST HTML/URL, receive screenshot/PDF/content. The self-hosted Docker image enables running Browserless on own infrastructure. For agents building web scraping, document generation, or testing workflows, Browserless reduces the operational complexity of running browsers to an API call.

API token authentication via token query parameter on WebSocket connections and REST calls. Tokens are generated in the dashboard. No fine-grained token scoping. Usage is tracked per-token with plan-based limits (concurrent sessions, total sessions per period). Self-hosted deployment uses a local token or no auth. No OAuth. Tokens don't expire. For agents, the per-plan concurrent session limit is the key constraint: each active browser session counts against the limit. Agents should close sessions promptly. The self-hosted Docker image provides unlimited sessions bounded only by infrastructure capacity.

Two integration paths: WebSocket for full browser automation and REST for simple operations. WebSocket: connect Puppeteer/Playwright to wss://chrome.browserless.io?token={token} — the browser runs in Browserless's cloud, the automation code runs in the agent's environment. REST endpoints: POST /screenshot (URL or HTML → PNG/JPEG), POST /pdf (URL or HTML → PDF), POST /content (URL → extracted HTML), POST /scrape (URL → structured content extraction with CSS selectors). The REST API is simpler for common operations: agents don't need Puppeteer/Playwright libraries for screenshots or PDFs. Session management enables persistent browser contexts. The API design clearly separates simple (REST) and complex (WebSocket) automation patterns.

REST API errors return JSON with descriptive messages. WebSocket connections may fail due to concurrent session limits — agents should implement connection retry logic. Session timeout: idle sessions are terminated after a configurable period (default 30 seconds) to prevent resource leaks. Browser crashes are handled by the platform — failed sessions can be retried. Screenshot and PDF generation can timeout on slow-loading pages — timeout parameters are configurable. The main reliability consideration: web scraping targets may block Browserless IP ranges. Residential proxy integration is available for scraping use cases. Self-hosted deployment avoids IP blocking issues but requires infrastructure management. For agents, implementing session cleanup (browser.close()) prevents session leaks.

Documentation at docs.browserless.io covers REST API, WebSocket connection, Docker deployment, and integration guides. The REST API documentation includes endpoint descriptions, parameters, and response examples. Puppeteer and Playwright connection guides show the one-line change needed to connect to Browserless. Docker deployment documentation covers self-hosted configuration. The documentation is focused and practical — the API surface is small enough for complete coverage. Code examples in JavaScript/TypeScript cover common patterns (scraping, screenshot, PDF). For agents, the REST API quick start (for simple operations) or the Puppeteer/Playwright connection guide (for full automation) are the entry points.