Skip to main content

Overview

The /browser endpoint fetches a URL with full JavaScript rendering. Unlike /fetch (which returns the raw HTTP response), /browser waits for dynamic content and returns the fully rendered page. When to use /browser instead of /fetch:
  • The page requires JavaScript to load content (SPAs, dynamic sites)
  • You need all cookies, including those set by client-side scripts
  • You want to execute custom JavaScript to extract data
  • You need a screenshot of the rendered page
The response format is the same as /fetch (meta, raw, raw_json), with additional fields for cookies, screenshots, and JS evaluation results.

Endpoint

Works just like /fetch — all parameters are passed via headers.

Request headers

Wait strategies

Cookies

Simple cookies — use the standard Cookie header:
Full cookie objects — use the X-Cookies header with a JSON array when you need domain, path, or httpOnly control:
Cookie object fields: name, value, domain, path, secure, httpOnly, sameSite, expires.

Steps

Execute sequential browser actions after the page loads — login flows, multi-page navigation, form filling, clicking through to specific content. Pass a JSON array via the X-Steps header:
Available actions: Each step runs after the previous completes. Add "continueOnError": true to a step to keep going if it fails. Example: Login → navigate → capture
Example: Login then stream live data
Steps work on both /browser (capture after all steps complete) and /browser/stream (stream during and after steps — step results arrive as step_ok / step_error events).

Resource blocking

Block specific resource types to speed up rendering:
Blocking images and fonts can reduce render time by 50%+ on media-heavy pages.

Response

Response validation

Use X-Expect-Selector and X-Expect-Contains to verify the rendered page has the content you expect. If validation fails, the API automatically retries on a different node before returning an error.

Examples

Render a JavaScript-heavy page

Wait for specific content

Extract data with JavaScript

The js_result field in the response contains the return value:

Capture a screenshot

With cookies

Route through a proxy

Validate response content

If the page doesn’t contain the expected content, the API retries on a different node:

Python

JavaScript


Browser Stream (SSE)

For live, long-running sessions, use /browser/stream. Instead of capturing a single snapshot, the browser stays open and streams events in real-time via Server-Sent Events. Only data-carrying requests (XHR/Fetch API calls) are captured — full HTML pages and JavaScript bundles are filtered out. No resources are blocked by default so pages load fully and widgets initialize correctly. Default wait strategy is networkidle. All data is gzip-compressed. Use cases:
  • Capture WebSocket frames that the page receives (live data feeds)
  • Monitor XHR/Fetch API calls the page makes (the actual data endpoints)
  • Watch DOM elements for changes (price updates, content changes)

Endpoint

Headers

Same headers as /browser, with different defaults: X-Wait-Strategy defaults to networkidle, X-Timeout defaults to 0 (runs until disconnect, 24h safety cap), no resource blocking. Plus:

SSE events

Example: Capture page WebSocket feed

The SSE stream runs until you disconnect. Each event arrives as event: type\ndata: json\n\n. Use curl -N (no buffering) to see events in real-time.

Example: Monitor network API calls

Example: Watch DOM element for changes

Python

Next steps

HTTP Fetch

For pages that don’t need JavaScript rendering, use the faster /fetch endpoint.

Error handling

Status codes, block detection, and retry strategies.