Legacy APIs (v2, v3, v4)

Older API versions, kept working for backwards compatibility. New projects should use the unified /api/v1.

These APIs are legacy. They keep working — existing integrations will not break — but new projects should build on the unified /api/v1. The v2/v3/v4 surfaces are frozen and will be sunset over time.

What changed

The old API versioned the whole surface (v2 → v3 → v4), so every improvement forced a migration. /api/v1 versions only the agent — platform resources (browsers, profiles, files, billing) are stable and shared, and each agent versions itself internally. See Quickstart and Choose an agent.

Where old things live now

Legacy	Unified /api/v1
POST /api/v2/tasks, POST /api/v3/sessions (the browser agent)	POST /api/v1/agents/browser-use/runs
POST /api/v4/sessions (the code + browser agent)	POST /api/v1/agents/browsercode/runs
v2/v3/v4 session file handling	Files (one workspace model, all agents)
v2 keep_alive / session-as-browser	automatic browser lifecycle — no flag
PATCH-to-stop a browser	POST /stop everywhere

Reference

The full endpoint reference for each legacy version is under the Legacy API v4 / v3 / v2 tabs. Use them only to maintain an existing integration.

• Skills stay on /api/v2/skills — still supported, unchanged.
• Backwards compatibility: your existing /api/v2, /api/v3, /api/v4 calls continue to work. Migrate to /api/v1 when convenient, not urgently.