Skip to main content
A Browser Profile is a saved snapshot of browser state (cookies, localStorage, and session files) that you can reuse across multiple runs. Profiles let you skip login steps and restore authenticated state instantly. Profiles are ideal when you:
  • Run the same agent repeatedly with the same account (daily data extraction, scheduled reports)
  • Want multiple agents to share the same authenticated state
  • Need to avoid repeated authentication to save time and steps

How profiles work

You can create a blank profile with only name and optional description, then pass that profile to future agent runs. Blank profiles are seeded from the configured default browser profile directory when available, with a minimal loadable profile skeleton as a fallback. When an agent runs with persist_browser_session=true, Skyvern archives the browser state (cookies, storage, session files) after the run completes. This archiving happens asynchronously in the background. Once the archive is ready, you can create a profile from it, then pass that profile to future agent runs to restore the saved state. For browser sessions, profile saving is opt-in: a session archives its state when it ends only if it has generate_browser_profile enabled or was started from a saved profile. See Save a session’s profile.

Create a Browser Profile

Create a blank profile when you want a reusable profile ID before any browsing has happened. Create a sourced profile when you want to capture cookies, localStorage, and session files from a workflow run or browser session.

Blank profile

Parameters:

From an agent run

Create an agent with persist_browser_session=true in the agent definition, run it, wait for completion, then create a profile from the run. Session archiving happens asynchronously, so add brief retry logic when creating the profile.
persist_browser_session must be set when creating the agent, not when running it. It is an agent definition property, not a runtime parameter.
Parameters:

From a browser session

You can also create a profile from a closed Browser Session that was set to save its profile. Create the session with generate_browser_profile enabled (or turn it on while the session is alive), close the session, then pass the session ID instead of the workflow run ID.
Sessions do not save their profile by default. If the session did not have generate_browser_profile enabled and was not started from a saved profile, this call fails with a 400 error — retrying does not help. Update API scripts and integrations that create profiles from closed sessions; n8n users may need updated Skyvern nodes. Profiles created from workflow runs (persist_browser_session=true) are unaffected.
For opted-in sessions, the archive uploads asynchronously after the session closes, so keep brief retry logic for the transient “not persisted yet” window.
Parameters:

Use a Browser Profile

Pass browser_profile_id when running an agent to restore the saved state. Skyvern restores cookies, localStorage, and session files before the first step runs.
Example response:
browser_profile_id is supported for agents only. It is not available for standalone tasks via run_task. You also cannot use both browser_profile_id and browser_session_id in the same request.

Tutorial: save and reuse browsing state

This walkthrough demonstrates the full profile lifecycle: create an agent that saves browser state, capture that state as a profile, then reuse it in a second agent. Each step shows the code and the actual API response.
1

Create an agent with persist_browser_session

The agent must have persist_browser_session=true so Skyvern archives the browser state after the run.
Response
2

Run the agent

Run the agent and wait for it to complete. Skyvern opens a browser, executes the navigation block, then archives the browser state in the background.
Response
3

Create a profile from the completed run

Archiving happens asynchronously after the run completes, so add retry logic. In practice the archive is usually ready within a few seconds.
Response
4

Verify the profile exists

List all profiles or fetch one by ID to confirm it was saved.
List response
5

Reuse the profile in a second agent

Pass browser_profile_id when running an agent. Skyvern restores the saved cookies, localStorage, and session files before the first block runs. The second agent starts with the browser state from step 2, no repeat navigation needed.
Response
6

Delete the profile

Clean up profiles you no longer need.
In a real scenario, step 1 would be a login agent that authenticates with a site. The saved profile then lets all future agents skip the login step entirely.

Pin a proxy identity

A browser profile can carry a pinned residential ISP proxy identity so that every run reusing the profile reaches the target site from the same IP and locale. Pinning is opt-in and uses two fields:
  • proxy_location — set to RESIDENTIAL_ISP (or a GeoTarget object) to opt the profile into a static ISP identity.
  • proxy_session_id — opaque Skyvern-managed sticky-session key. Omit it to let Skyvern generate one automatically when proxy_location is RESIDENTIAL_ISP.
When a run uses a profile that has a pinned proxy, Skyvern routes traffic through the same residential ISP identity the profile was last associated with, even if the run request does not set proxy_location.

Set a pin at create time

Rotate the pinned identity

Update the profile with rotate_proxy_session_id: true to ask Skyvern to mint a fresh sticky-session id while keeping the same proxy_location. Use this when the existing IP gets flagged or when you want to start a new identity for the same profile.
cURL
To clear the pin entirely, set proxy_location to null in the same update call.
proxy_session_id is only valid alongside RESIDENTIAL_ISP. Requests that supply proxy_session_id with any other proxy_location are rejected with a 400.

Best practices

Use descriptive names

Include the account, site, and purpose in the profile name so it is easy to identify later.

Refresh profiles periodically

Session tokens and cookies expire. Re-run your login agent and create fresh profiles before they go stale. Adding the date to the name makes it easy to track which profile is current.

Capture updated state after each run

To capture state changes during a run (like token refreshes), the agent must have persist_browser_session=true in its definition. This lets you create a fresh profile from each completed run.

Next steps

Browser Sessions

Maintain live browser state for real-time interactions

Cost Control

Optimize costs with max_steps and efficient prompts