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
/fetch (meta, raw, raw_json), with additional fields for cookies, screenshots, and JS evaluation results.
Endpoint
/fetch — all parameters are passed via headers.
Request headers
Wait strategies
Cookies
Simple cookies — use the standardCookie header:
X-Cookies header with a JSON array when you need domain, path, or httpOnly control:
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 theX-Steps header:
Each step runs after the previous completes. Add
"continueOnError": true to a step to keep going if it fails.
Example: Login → navigate → capture
/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:Response
Response validation
UseX-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
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.