Skip to main content
To move a browser-use workflow to pre.dev, express the browser objective as a task, submit it to the hosted service, and handle the returned task outcome. The request and lifecycle differ from a locally managed agent, so plan the migration around behavior and result contracts.

​
Map the concepts

​
Submit a first task

Set PREDEV_API_KEY in your environment first. Save the returned id, then retrieve the run. Wait for terminal batch status and inspect every task’s status; a completed batch can contain failed tasks.

​
Check assumptions before migrating

The public request schema does not provide a persistent browser-profile or cookie-jar management API. Plan authentication inside the supported task workflow rather than assuming your local browser session transfers to the service. Use an explicit output schema where your application depends on a stable result shape. Pending results can be null or partial. Report blocked, timed-out, and failed tasks as such instead of treating missing data as successful extraction. For retry behavior, use the REST idempotency option. SDK 1.1.0 does not expose every newer request control in its typed interfaces; the SDK guide identifies when direct REST is needed.

​
Validate the migration

Run a representative authorized task and compare the required behavior and data with your existing workflow. Then add bounded polling, error handling, and concurrency appropriate to your account. Published benchmarks describe their own datasets and dates; measure your workload before relying on a cost or speed estimate.