---
title: "Migrate from AdsPower to Scalebrowser"
description: "Move from AdsPower: keep Local API scripts on the compatible adapter, create the profiles fresh, sign in again, and give every profile its own exit address."
canonical: "https://scalebrowser.net/docs/migrate/adspower"
last_modified: "2026-11-14T17:26:55.000Z"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://scalebrowser.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Migrate from AdsPower to Scalebrowser

> Move from AdsPower: keep Local API scripts on the compatible adapter, create the profiles fresh, sign in again, and give every profile its own exit address.

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](/docs/adspower) 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](/docs/rest) 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](/docs/profiles) |
| 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](/docs/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](/docs/adspower#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](/docs/fleet)). 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](#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](#extensions) below.

> **Note**
>
> **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](/docs/account/plans#the-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](/docs/credentials).

## 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.

> **Warning**
>
> **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](/docs/proxies#one-gateway-many-profiles). A setup that needs a shared address can [turn the rule off](/docs/proxies#turning-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](/docs/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"
```

> **Warning**
>
> **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](/docs/adspower#switch-it-on) 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](/docs/rest) or an [SDK](/docs/sdks).

## 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](/docs/sdks), or let an agent work the profile over the [MCP server](/docs/agents/mcp-server). Both send every click and keystroke through the [human input layer](/docs/behaviour). [What the page still sees](/docs/migrate/playwright#what-the-page-still-sees) lists what a page receives from each tool.

## Next

- [AdsPower adapter](/docs/adspower): the fourteen routes, and the four behaviours that differ.
- [Groups, presets & bulk](/docs/fleet): making many profiles at once.
- [Credentials & logins](/docs/credentials): storing a login so an agent signs in without seeing it.
- [Migrate overview](/docs/migrate): the two steps, and what maps to what.