Multi-Account Browser Automation Glossary: 31 API Terms for 2026

Automation vocabulary gets used loosely, and loose vocabulary causes real bugs. Someone says "the headless flag is breaking our sessions" when the stack was never headless at all. The real problem is an orchestrator that times out mid-launch, retries without an idempotency key, and stacks duplicate sessions on one profile ID until two browsers are writing to the same cookie jar.

There are decent glossaries for the profile-management side (proxies, identity parameters, cookies) and decent glossaries for the automation side, written for people driving stock Chromium. Few cover the seam where they meet, which is where automating a multi-account browser actually lives. So here are 31 terms from that seam, defined the way you would explain them to a new hire on day one.

1. The launch layer

CDP (Chrome DevTools Protocol) — the JSON-over-WebSocket protocol Chromium speaks to whatever is driving it. Same protocol your DevTools panel uses. Every serious browser automation library sits on top of it.

WebSocket endpoint — the ws:// URL a launched browser exposes for CDP traffic. This is the handoff point: the profile API hands you a URL, your script connects to it. Lose the URL, lose the session.

Headless — Chromium running with no visible window. Faster, cheaper on RAM, and (since Chrome's "new headless" mode landed) far closer to headful behaviour than it used to be. It is a launch mode. Nothing more. On JustBrowser's local API, POST /profiles/{id}/start launches headless unless the request body says {"headless": false}.

Headful / headed — the opposite, with a real window and a real compositor. Still the better choice for anything where you need to watch a login flow happen.

Browser context — an isolated cookie-and-storage container inside one browser process. Useful for tabs that shouldn't know about each other. Not a substitute for separate profiles, because contexts share the same engine-level identity. When you attach to a running profile, use its existing context (contexts[0]); a new context sits outside the profile's cookies and storage.

2. Driving the browser: automation libraries

Playwright — Microsoft's automation library. Auto-waiting, decent tracing, first-class Python and Node bindings. What most new browser automation gets written in.

Puppeteer — the older Chrome-only library. Thinner, closer to raw CDP, still fine if you know what you want.

Selenium / WebDriver — the HTTP-based standard that predates all of this. Slower, more verbose, still what half of enterprise QA runs on.

WebDriver BiDi — the newer bidirectional standard meant to give WebDriver the event-streaming powers CDP has. Adoption in 2026 is real but uneven, which is a polite way of saying that different tools support different subsets of the spec. New code is safest against CDP, with BiDi worth watching.

connectOverCDP() — the Playwright call that attaches to an already-running browser instead of launching its own. This is the single most important function name when you automate a multi-account browser. You never want the library launching its own Chromium, because that's a stock binary with none of the profile's settings, cookies or proxy. You want it attaching to the one the profile started. A common bug is calling launch() where connect() was meant, and the automation quietly runs in the wrong browser.

3. The REST surface

REST API — the HTTP control plane for profile lifecycle: create, list, launch, stop, delete. On JustBrowser it is local, bound to 127.0.0.1, and comes with the plan ($9.99/mo, unlimited profiles); it answers during the 7-day trial too, so you can script against it before the first charge. Team seats don't get API access.

Endpoint — one URL plus method that does one thing. POST /profiles/{id}/start is an endpoint. Obvious, but people use it to mean "the whole API" and then nobody knows what's being discussed.

Idempotency key — a client-generated string you attach to a request so retrying it can't cause the action twice. The server remembers the key and replays the original result. It is the fix for the classic overnight failure: a launch times out client-side, gets retried, and two browsers end up on one profile.

Polling — asking "is it ready yet?" on a loop. Simple, wasteful, and the reason half of all rate-limit errors exist. If your platform ships webhooks and you're still polling every 500ms, the rate limit isn't the real problem.

Webhook — the inverse: you register a URL, the platform POSTs to it when something happens. Profile launched, profile crashed, session expired. Not offered on JustBrowser's local API — poll GET /profiles/{id}/status or GET /system/status from your scheduler instead. The profile automation walkthrough covers the lifecycle patterns properly.

4. Rate limits and retries

Rate limit — the server's cap on how many requests you get per window. Most APIs you automate against have one, and the sites your profiles visit have their own. Yours is probably lower than you think.

HTTP 429 — "Too Many Requests." Not an error in your code. A message that your pacing is wrong.

Exponential backoff — doubling your wait after each consecutive failure. 1s, 2s, 4s, 8s, cap it. The full implementation lives in the rate limit and backoff guide if you want working code rather than a definition.

Jitter — adding randomness to each backoff delay. Without it, twenty workers that failed together retry together, forever, in perfect lockstep. This is called the thundering herd, and it is easy to spot in a log file.

Circuit breaker — a wrapper that stops calling a failing service entirely after N consecutive failures, waits, then lets one probe request through. Borrowed from distributed systems. Underused here, and it's the difference between a bad ten minutes and a bad night.

5. Concurrency and queueing

Concurrency limit — how many operations you allow in flight at once. Server-side there's a ceiling you don't control; client-side there's one you do. Set yours below theirs.

Worker pool — a fixed set of workers pulling from a shared queue. Bounded by design, which is the whole point.

Semaphore — the primitive underneath. A counter with N slots; acquire before launching, release after. Five lines of code that prevent most self-inflicted 429s. (Yes, five. p-limit in Node, asyncio.Semaphore in Python.)

Backpressure — what a system does when work arrives faster than it can be processed. Good answer: slow the producer. Bad answer: buffer everything in memory until the box swaps. Concurrent profile launches against API rate limits digs into where the ceiling actually sits.

6. Session and state

Profile — the persistent environment a multi-account browser maintains: identity parameters, cookies, local storage, history, proxy binding. The unit everything else is about.

Session persistence — whether that state survives a restart. If your cookies reset on every launch, your profile isn't persisting anything.

Cookie export — serializing a profile's cookie jar out to JSON so it can move between machines or into a test. Also how you accidentally leak a live session into a git repo, so mind your .gitignore.

Profile lock — the mechanism preventing two processes from opening the same profile at once. If your browser doesn't enforce this, your orchestrator has to.

7. Ops vocabulary

Orphaned process — a browser that's still running after the thing that launched it gave up. Eats RAM, holds file locks, and shows up in ps aux long after the job that started it is gone.

Graceful teardown — closing pages, then the context, then the browser, then confirming the process actually exited. Most scripts do the first step and call it done.

Health check / heartbeat — a cheap periodic request that confirms a session is still alive. Ten lines. Catches the failure mode where your script is happily driving a browser that died four minutes ago.

Honorable mentions (not in the 31)

Trace viewer — Playwright's recorded timeline of a run. Not specific to multi-account browsers, but the fastest way to find out which step actually failed.

Device pixel ratio — a profile parameter that's easy to forget when you set a viewport size by script. If your pages render differently under automation than by hand, check it alongside the viewport.

Quick verdict

If you only internalize one distinction from all of this: headless is a launch mode, and a profile's identity parameters are a property of the engine, and they have nothing to do with each other. A good share of "my automation behaves differently" problems come from conflating them and then changing the wrong variable.

The rest of it is plumbing, and plumbing vocabulary is worth learning precisely because it's boring. Idempotency keys aren't interesting. They're just the difference between a retry and a duplicate session. And duplicate sessions on one profile are a common cause of confusing behaviour, including a site ending a session because one login now appears in two places.

One more reference worth bookmarking if you work across stacks: the browser telemetry API reference, for the instrumentation half of the problem. Different vocabularies, overlapping problems.

Automate only accounts and sites you are allowed to automate, and check each site's terms and rate limits first. WebDriver BiDi is likely to change some of these definitions over the next eighteen months.

Frequently Asked Questions

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

Headless describes a launch mode: Chromium running with no visible window, driven entirely over a protocol. A multi-account browser is a tool that gives each profile its own cookies, storage, proxy and identity parameters. They're orthogonal. You can run a headless profile, and plenty of people do. A headless session has no real window, so its screen and viewport follow headless defaults, which is why a session that needs to behave like a visible browser should start headed. Confusing the two is how teams end up toggling headless mode as a fix and wondering why nothing changed.

Do I need CDP if the browser already has a REST API?

You need both, and they do different jobs. The REST API is for lifecycle: create a profile, launch it, check status, delete it. CDP is for what happens inside the page once it's open: clicking, typing, intercepting network requests, reading the DOM. On JustBrowser, the REST call returns a cdp_url, and Playwright or Puppeteer attaches to that endpoint over CDP. REST gets you the door. CDP is you walking through it.

What's the right retry strategy when a profile launch returns 429?

Exponential backoff with jitter, plus an idempotency key on the original request. Double the wait each attempt (say 1s, 2s, 4s, 8s), cap it around 30 seconds, and add random jitter so twenty workers don't all retry on the same tick. The idempotency key matters more than the backoff: without it, a launch that succeeded server-side but timed out client-side gets retried into a second live browser process nobody is tracking.

Which of these terms actually matter if I'm running fewer than 10 profiles?

About eight of them: profile, headless, CDP, WebSocket endpoint, session persistence, cookie export, graceful teardown, and 429. The concurrency vocabulary (semaphores, worker pools, backpressure, circuit breakers) only starts paying rent somewhere north of 20 or 30 parallel profiles. Learn it before you scale, not during. But don't build a distributed queue for five profiles running a nightly cron.

---

Try JustBrowser

A multi-account browser for teams, built on a custom Chromium engine, not an extension. Real C++ engine patches at the canvas / WebGL / audio / font / screen layer, so each profile's 40+ identity parameters are consistent. 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