Browser Agents
Migrate a browser workflow
Translate a locally managed browser workflow into pre.dev tasks and results.
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
| Existing workflow | pre.dev equivalent |
|---|---|
| Launch a browser and choose a starting page | Set the task’s url |
| Describe the agent’s goal | Set instruction and optional successCondition |
| Parse output into a model | Supply an output JSON Schema |
| Run several independent jobs | Put tasks in one array and request concurrency |
| Limit steps or wall time | Set maxSteps and maxDurationSeconds per task |
| Track a long-running job | Submit async: true, persist the ID, and poll or attach to SSE |
| Inspect the browser | Request available events, screenshots, or the live browser URL |
Submit a first task
curl --fail-with-body https://api.pre.dev/browser-agent \
-H "Authorization: Bearer $PREDEV_API_KEY" \
-H 'Content-Type: application/json' \
-d '{
"tasks": [{
"url": "https://example.com",
"instruction": "Read the page title",
"mode": "extract",
"maxSteps": 5,
"maxDurationSeconds": 30,
"output": {
"type": "object",
"properties": {"title": {"type": "string"}},
"required": ["title"]
}
}],
"async": true
}'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.