Migrate from AdsPower to Scalebrowser

An AdsPower setup has two halves, and they move differently. The scripts that call AdsPower's Local API can keep running: the daemon has an AdsPower adapter that answers the same routes in the same shape. The profiles do not move. Each one is created fresh here, and its logins are made again, by you in the profile's window or by an agent that stores them in the vault.

What maps to what

In AdsPower	In Scalebrowser
A profile, called a `user` and keyed by `user_id`	A profile, keyed by its profile id. On the adapter that id is the `user_id`, so the adapter and the REST API address the same profiles
Fingerprint settings sent with `user/new`	Nothing to set. The identity is drawn from the profile's seed, and its GPU, screen, fonts and voices are your machine's own. See Profiles & personas
A proxy sent with `user/new` or `user/update`	A proxy stored once and assigned to the profile, in the app or over REST
Groups	Groups, as flat labels. The adapter's `group/*` routes list, create, rename and delete them
Opening a profile to work in it by hand	Start in the app, or `browser/start` on the adapter without `headless`. Both open a visible window
Puppeteer or Playwright attached to `ws.puppeteer`	The same field on the adapter, or `cdp_ws` from the native start. See Direct CDP

What carries over, and what does not

Your scripts carry over. The routes, the query parameters, the {code, msg, data} envelope and the visible window by default are AdsPower's, so a script that calls 127.0.0.1:50325 needs no change beyond the profile ids below. What your script has to change lists the four behaviours that differ.

Profiles, fingerprints, cookies and logins do not. Nothing is imported from AdsPower:

Profiles are created fresh. Make them one at a time with user/new on the adapter, or many at once from a preset with POST /v1/bulk/profiles (Groups, presets & bulk). Each one gets a new id, so a script that names user_id values needs the new ones, and user/list returns them.
Each new profile draws its own identity. user/new reads name and group_id and nothing else, so a fingerprint or a proxy in the request is ignored. The persona is generated here as one coherent set, because a mixture of values chosen by a client is what makes a profile detectable.
Cookies and logins start empty. Session import opens only a bundle that a Scalebrowser profile exported, and the credential bundle works the same way. Logins below is how a new profile gets signed in.
Proxies are stored again. The adapter's proxy/list reads the proxies stored here, and no adapter route creates one.
Extensions are uploaded again. See Extensions below.

Count your profiles before you recreate a large fleet. Your plan sets how many profiles you keep and, separately, how many browsers run at the same time. A batch that would pass the profile number creates nothing and answers 4014. See Plans & limits.

Logins

Two ways, and you can mix them per site:

Sign in by hand once. Start the profile with a window, sign in, and stop it. Cookies and storage stay in the profile's browser directory between starts.
Store the login in the profile's vault. With Add login on the profile's page in the app, with PUT /v1/profiles/:id/credentials/:platform, or from an agent with credential_store. An agent then signs in with credential_fill and never sees the password. Store the 2FA setup key beside it, and the daemon computes the six-digit codes itself. See Credentials & logins.

Proxies

Store each proxy once, as http, socks5 or a provider gateway, and assign it: in the app under Proxies, with PATCH /v1/profiles/:id and a proxy_id, or for many profiles at once with POST /v1/bulk/assign-proxy. Under the default geo_mode, a profile takes its timezone and language from the country its proxy exits in.

One exit address belongs to one profile. If several of your AdsPower profiles shared one fixed proxy, only the first to start here keeps that address. The next one is refused with 4013 for as long as the first one owns it, which is 3 to 90 days by the kind of address. A provider gateway gives every profile its own address from one account; see One gateway, many profiles. A setup that needs a shared address can turn the rule off.

Extensions

Upload the .crx of each extension your profiles used to the library, then assign it per profile or with POST /v1/bulk/assign-extensions. Two kinds of package are refused at upload: one without a key in its manifest, and Manifest V2. See Extensions.

Keep the scripts on the adapter

The adapter is off by default. One line in the daemon's config switches it on:

toml

adspower_bind = "127.0.0.1:50325"

Close AdsPower first. Both listen on port 50325, and a daemon that cannot bind the adapter's address does not start. If something else keeps the port, bind the adapter to another loopback port and change the base URL in your scripts.

AdsPower adapter has the rest: the environment variable, the check with curl, and the fourteen routes. Once the scripts run, the adapter has done its job. Detector pages probe port 50325 to guess which tool a machine has installed, so switch the adapter off again once your scripts use the REST API or an SDK.

Beyond the adapter

Attaching Puppeteer or Playwright to a profile changes the browser, not how your script clicks and types. For sites that grade input, drive the page with the SDKs, or let an agent work the profile over the MCP server. Both send every click and keystroke through the human input layer. What the page still sees lists what a page receives from each tool.

AdsPower adapter: the fourteen routes, and the four behaviours that differ.
Groups, presets & bulk: making many profiles at once.
Credentials & logins: storing a login so an agent signs in without seeing it.
Migrate overview: the two steps, and what maps to what.