Check browser proxy support before wiring products together

The current browser route rejects custom proxy routing

Lupin's Cloudflare Browser Run integration does not support custom Lupin proxy routing. Browser creation explicitly rejects proxy_user_id with proxy_not_supported. This is a product boundary to account for before allocating either resource. Owning a proxy user and a browser session in the same workspace does not connect their network paths automatically. Start by identifying whether the task needs rendered-page automation or a proxy-enabled HTTP client. If the requirement specifically combines them, verify a supported integration path with the operator rather than presenting two successful resource creations as a working combined solution.

Keep the two credential models distinct

A proxy connection uses the returned host, port, username and password. A browser session uses organization-authorized API actions and temporary live-view or CDP access links. Passing a proxy password into a page form or appending it to a browser access URL does not configure the browser's network route. It can instead leak credentials. Likewise, the caller's Lupin API authorization is not forwarded to public pages as a proxy setting. Keep these credentials in their appropriate trusted client layers and redact them from task summaries, logs and screenshots.

Choose a supported route for the task

If the work only needs an HTTP fetch through a proxy, use a client whose proxy support is documented and configure it from the connection block. If it needs browser interaction through Lupin, use the current Browser Run surface with its actual routing limitations. A sandbox may run software with its own network capabilities, but Lupin does not automatically install or certify every browser-client and proxy combination there. Treat such a workload as a separately reviewed execution task with explicit dependencies, authority and verification. Do not claim it is the managed browser product or inherits that product's lifecycle controls.

{"name":"research-task","proxy_user_id":"pxu_existing_resource"}

Verify integration at the network boundary

A successful proxied request from one client does not prove a different browser connection uses the same route. Verification needs to observe the actual client and endpoint under the intended configuration. Keep tests small, approved and free of unnecessary private data. Distinguish a source-reviewed setup from a live connection test, and never claim a provider path was tested just because its code accepted parameters. Browser sessions have temporary state and finite runtime; proxy users have allocation and refill behavior. A combined workflow must track both cost and cleanup boundaries independently.

Fail early when the requirement is unsupported

Surface the routing limitation before a paid allocation or a long automation plan depends on it. A bootstrap key cannot create paid resources, and a fully authorized key still cannot make an unsupported parameter valid. If the task can be narrowed to a public browser read or a standalone proxied HTTP request, choose that smaller supported operation. Otherwise retain the concrete requirement for an operator or future integration change. The useful result is an accurate integration decision and a reviewable alternative, not a diagram that silently assumes shared routing between products the API keeps separate.

Sources & verification

Reviewed against the current Lupin route, provider adapter and shared input contracts, plus the linked official references. Examples were not run against live services.

• developers.cloudflare.com · browser-run · reference · browser-binding-api ↗Checked 2026-11-05
• docs.dataimpulse.com · proxies · protocols ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.