Use a browser when the initial HTML is not enough
Product lists might not become available until JavaScript finishes executing. Similarly, a page might need a specific selector to load before its data becomes accessible. Browser mode manages data retrieval by running within a browser environment, all while maintaining compatibility with Data API submission, polling, and result endpoints.
Begin by selecting a representative target. Then, check the returned data against the specific fields your application requires. HTTP requests often work fine even on JavaScript-heavy pages; opt for browser execution only when it provides data that HTTP cannot fetch, not merely because it appears more powerful.
Submit, poll, and validate
This illustrative body requests browser acquisition. Send it from your backend with an API key and an idempotency key. Save the returned request ID, poll until completed, then retrieve the result.
- Configure supported waits for the element or text that signals useful content.
- Inspect the terminal state and public error fields before retrieving a result.
- Check that the result contains the expected records, rather than a login or challenge page.
{
"url": "https://example.com/catalog",
"mode": "browser",
"proxy": "random"
}Rendering is one part of collection
Using browser execution doesn't guarantee access to all targets, specific latency levels, or fully loaded lazy content. Standard constraints like timeouts, target behavior, and account limits remain in effect. Consult the effective route and billing metadata to calculate expenses accurately.
For reusable multi-step automation with published versions and run history, use Browser Workflows. A single browser-mode request and a versioned workflow are different contracts.