Multi-Account Browsers for Developers: Free Tiers, Trials and REST APIs Compared

A Puppeteer script that behaves differently from the profile you configured can have a perfectly good profile and proxy. A common cause is connecting to a standard Chrome instance while assuming the multi-account browser's profile settings carry over.

They don't.

The difference matters: multi-account browsers built for operators (affiliate marketers, e-commerce sellers) and multi-account browsers built for developers are fundamentally different products. Most tools in this category were designed for people who click buttons in a GUI — not for engineers who want to spin up 50 profiles from a script at 3am.

This guide covers the multi-account browsers with REST APIs and SDK support, how their free tiers and trials differ, and what the actual integration process looks like. (JustBrowser, which publishes this blog, has a trial rather than a free tier; more on that below.)

Why Developers Need Multi-Account Browsers (Not Just Operators)

The typical multi-account browser pitch goes something like: "Run multiple accounts side by side." And sure, that's the operator use case. But developers have different problems.

Collecting public data at scale means running many sessions, and each one needs its own cookies, storage, proxy and consistent identity parameters, so that runs don't contaminate each other. Respect each site's terms and robots rules while you do it. (If you're building data pipelines that feed into analytics dashboards, JustAnalytics can help visualize the data you're collecting.)

QA automation needs multiple browser configurations. Testing how your app renders for a Windows user in Germany versus a Mac user in Japan means more than just changing the User-Agent string. You need consistent profiles whose parameters agree with each other.

Ad verification requires geo-distributed, device-diverse browser profiles to check how ads render across different user segments. (This pairs well with click fraud detection tools like ClickzProtect if you're validating both the ad rendering and the traffic quality.)

Account testing for SaaS products often requires isolated browser environments. If you're building multi-tenant software and need to test how different accounts interact — cookie and storage isolation matter.

The common thread: you need programmatic control over browser profiles, and you need it to work with your existing automation stack.

Looking for JustBrowser's API reference? It lives at justbrowser.app/docs — 108 operations with parameters, request and response bodies and error codes, plus the raw OpenAPI document at /docs/openapi.json. Two things worth knowing before your first call: the API is local, bound to 127.0.0.1:36542 (there is no hosted endpoint), and POST /profiles/{id}/start starts headless unless you send {"headless": false}.

Core Concepts: What Makes a Multi-Account Browser Developer-Friendly

Before comparing specific tools, here's what matters for developer workflows:

REST API access. Can you create, launch, and manage profiles via HTTP calls? This is table stakes for scripted runs and headless automation.

CDP (Chrome DevTools Protocol) support. Playwright and Puppeteer connect to browsers via CDP's WebSocket endpoint. A multi-account browser needs to expose this endpoint with the profile's identity parameters in effect.

Headless mode. Running without a GUI is useful for automation. Be aware that a headless session has no real window, so its screen and viewport follow headless defaults; use headed mode when a session must behave like a person's browser.

Profile management via code. Creating a profile, configuring its fingerprint, assigning a proxy, launching it, grabbing the CDP endpoint, and shutting it down — all via API. If any step requires the GUI, your automation breaks.

Selenium support. Some teams are locked into Selenium. WebDriver-based control needs a different integration path than CDP.

The Complete Process: Connecting Automation Frameworks

Here's how the integration works. JustBrowser is the primary example, with notes on how GoLogin and AdsPower differ.

Step 1: Create a Profile via REST API

// JustBrowser API example
const API = 'http://127.0.0.1:36542/api/v1';

const response = await fetch(`${API}/profiles`, {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${API_KEY}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    // field names are illustrative; the full schema is at justbrowser.app/docs
    name: 'scraper-profile-001',
    os: 'windows',
    proxy: {
      type: 'http',
      host: 'proxy.example.com',
      port: 8080,
      username: 'user',
      password: 'pass'
    }
  })
});

const profile = await response.json();
// profile.data.id is what you'll use to launch

GoLogin's API is hosted and authenticated with a token from your GoLogin account. AdsPower runs a local API server, by default on port 50325. Each documents its own flow.

Step 2: Launch the Profile and Get CDP Endpoint

// Start the browser profile. With no body it starts headless;
// send { "headless": false } as JSON for a visible window.
const launchResponse = await fetch(
  `${API}/profiles/${profile.data.id}/start`,
  {
    method: 'POST',
    headers: { 'Authorization': `Bearer ${API_KEY}` }
  }
);

const { data } = await launchResponse.json();
const cdpUrl = data.cdp_url;
// cdpUrl looks like: ws://127.0.0.1:<port>/devtools/browser/abc123

This is where things get interesting. The browser launches locally on the Windows or Mac machine running JustBrowser, and the profile's configuration came from the API. The CDP endpoint lets your automation framework take over.

Step 3: Connect Playwright

const { chromium } = require('playwright');

const browser = await chromium.connectOverCDP(cdpUrl);
const context = browser.contexts()[0];
const page = context.pages()[0] || await context.newPage();

await page.goto('https://browserleaks.com/canvas');
// The canvas output will match the profile's configured identity

Puppeteer works nearly identically:

const puppeteer = require('puppeteer-core');

const browser = await puppeteer.connect({
  browserWSEndpoint: cdpUrl
});

Step 4: Selenium Integration (Different Path)

Selenium doesn't use CDP directly. Instead, you start the profile, ask the API for that profile's debugger address, then point Selenium at it:

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
# Pin ChromeDriver to the engine's current major version (the docs say where to read it),
# or Selenium Manager fetches a driver for your installed Chrome and the attach fails.
# fetch the per-profile debugger address first
# GET http://127.0.0.1:36542/api/v1/profiles/{id}/selenium  (Authorization: Bearer <token>)
options.add_experimental_option("debuggerAddress", debugger_address)

driver = webdriver.Chrome(options=options)
driver.get("https://browserleaks.com/canvas")

The multi-account browser needs to be running before Selenium connects. Less elegant than CDP. Clunkier. But it works.

Step 5: Cleanup

// Stop the profile when done
await fetch(
  `${API}/profiles/${profile.data.id}/stop`,
  {
    method: 'POST',
    headers: { 'Authorization': `Bearer ${API_KEY}` }
  }
);

Always stop profiles when you're done. Running dozens of zombie browser instances is a resource drain and, for cloud-synced tools, might hit profile limits. Clean up after yourself. Future you will thank present you.

Free Tier Comparison: What You Actually Get

Free tiers in this category are real, but they come with profile limits, and API access is usually reserved for paid plans. The details change often, so the table points you at each vendor's own published plans rather than repeating figures that go stale.

We don't have a free tier to put in that column — JustBrowser is a seven-day trial and then $9.99/mo, and the trial holds nothing back, so you're validating scripts against unlimited profiles and the live API rather than a crippled build. With the others, read the published limits before you plan a test suite around their free plans.

One opinion: if you're a developer evaluating these tools, skip the free tier comparison entirely. What matters is the API design, documentation quality, and whether the tool actually works with your automation framework. Sign up for a trial, run your scripts, and see what breaks. Free tier profiles are good for "does it install" — not for "will it survive production."

Advanced Tips for Automation Engineers

Status polling. JustBrowser's API has no webhooks — poll GET /profiles/{id}/status to track launch state, and wrap your CDP session in reconnection logic to catch crashes.

DNS-over-HTTPS per profile. JustBrowser supports per-profile DNS-over-HTTPS (Cloudflare, Google, Quad9 or a custom template). This matters if you're testing geo-specific behavior where DNS responses differ by region.

Long-lived sessions. For long-running automation and testing (like keeping a QA or client account session stable), keep each profile's proxy stable. A rotating IP undermines a long-lived profile, which is why our step-by-step ISP-proxy setup for JustBrowser leans on static addresses for stable sessions.

Consistency checks before production. Check that each profile's timezone, language, proxy location and platform agree with each other, and confirm WebRTC isn't exposing your real IP (BrowserLeaks shows this). Your specific proxy + profile combination matters, as does the JA4 TLS fingerprint at the network layer, which browser-side tools never check. Trust but verify.

Error handling for CDP disconnections. Browser processes can crash. Your Playwright/Puppeteer code needs reconnection logic. Don't assume the CDP endpoint stays alive forever.

Common Mistakes Developers Make

1. Assuming a profile's identity carries over to a regular browser. If you export cookies and import them to a regular Chrome instance, the profile's identity parameters don't come with them. You need to launch through JustBrowser every time — it's one of the myths that quietly cause problems.

2. Ignoring proxy quality. A well-configured profile behind a poor proxy gives inconsistent results, and some sites treat datacenter addresses differently. Budget for proxies that fit the task. (If you run the sites you're verifying, JustAnalytics shows how real visitors reach them. And if your team needs mailboxes on several of its own domains, JustEmails provides custom-domain email while JustBrowser handles browser isolation.)

3. Running too many concurrent profiles. Each profile is a separate browser process. 20 profiles means 20 Chromium instances. Size the Windows or macOS machine accordingly; each browser instance can use several hundred megabytes or more under load.

4. Ignoring engine updates. A browser engine that falls behind upstream Chromium drifts from what real browsers do. JustBrowser's engine is patched on every upstream Chromium release; check that any tool you choose keeps pace.

5. Hardcoding CDP ports. Use the cdp_url the API hands back on start. Hardcoding a fixed debugger port works until you try to run two profiles simultaneously.

Frequently Asked Questions

Which free multi-account browsers have REST API support?

JustBrowser has no free tier, but its local REST API is included in the one plan ($9.99/month or $99.99/year) and is live during the 7-day trial (card required), so you can automate against it before the first charge. Other vendors decide plan by plan which tiers include API access and change it over time, so check their published plans before you build on a free tier elsewhere.

Can I use Playwright with a multi-account browser?

Yes. JustBrowser, GoLogin and AdsPower all support Playwright through the Chrome DevTools Protocol (CDP). With JustBrowser you start the profile through the local REST API, take the cdp_url from the response, and connect Playwright with connectOverCDP(). GoLogin and AdsPower document their own launch flows.

What's the difference between headless and headed multi-account browser automation?

Headed mode runs the full browser UI — slower, but the window and screen behave like a person's browser. Headless mode runs without a UI, faster for scraping and testing, and its screen and viewport follow headless defaults. JustBrowser supports both through the REST API; POST /profiles/{id}/start starts headless unless you send {"headless": false}.

Are free multi-account browser tiers good enough for development testing?

For basic testing and proof-of-concept work, often yes. JustBrowser is the odd one out here — there's no free tier, just a 7-day trial (card required) that withholds nothing, so you validate scripts against unlimited profiles and the real API rather than a cut-down version of the product. For production automation you'll be on a paid plan regardless of which tool you choose.

---

Try JustBrowser

Native Chromium multi-account browser for teams — not extension-based. Real C++ engine patches at the canvas / WebGL / audio / font / screen layer, across 40+ identity parameters. Local REST API + CDP for Playwright, Puppeteer, Selenium. $9.99/month or $99.99/year. 7-day free trial, card required — cancel any time in the seven days and you are not charged. Unlimited profiles.

Get started → · How it differs from Multilogin / GoLogin / AdsPower · More guides on the JustBrowser blog