Antidetect Browser Automation Glossary: 31 API Terms for 2026

1:40 in the morning, a contractor pings me: "the headless flag is getting our profiles banned, I'm killing it." Nothing in that sentence about antidetect browser automation was correct, which is roughly why this glossary exists.

The stack wasn't headless. It was launching full windowed Chromium on a Mac mini in his spare room, attaching Playwright to the antidetect browser over a WebSocket, and running about forty profiles a night. What was actually happening: his orchestrator kept timing out mid-launch, retrying without an idempotency key, and stacking duplicate sessions on the same profile ID until two browsers were writing to the same cookie jar. The platform saw one account driving two contradictory sessions from one IP. Ban.

Took us ninety minutes to find, mostly because we spent the first forty arguing about a word neither of us was using the same way.

That's the thing about this corner of the industry. There are decent glossaries for the operator side — canvas hashes, proxies, fingerprint entropy — and decent glossaries for the automation side, written by people who assume you're driving stock Chromium and have never had an account nuked. Almost nobody covers the seam where they meet — which is exactly where antidetect browser automation actually lives. So here's 31 terms from that seam, defined the way I'd 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 antidetect 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 less obviously different from headful than it used to be. It is a launch mode. Nothing more.

Headful / headed — the opposite, with a real window and a real compositor. Still what I default to for anything touching a login flow.

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 — contexts share the same engine-level fingerprint.

2. Driving the browser: antidetect browser automation libraries

Playwright — Microsoft's automation library. Auto-waiting, decent tracing, first-class Python and Node bindings. What most new scraping work 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 my polite way of saying I've read three vendor posts claiming full BiDi support and found three different subsets of the spec sitting behind them. I'd write new code against CDP and watch BiDi.

connectOverCDP() — the Playwright call that attaches to an already-running browser instead of launching its own. This is the single most important function name in antidetect automation. You never want the library launching Chromium — that's a stock binary with none of your identity patches. You want it attaching to the one your antidetect engine started. I got this wrong for most of a month. Wrote a whole post-mortem, blamed the proxy vendor, blamed the canvas seed — the bug was launch() where connect() should have been. One word.

3. The antidetect browser REST surface

REST API — the HTTP control plane for profile lifecycle: create, list, launch, stop, delete. On JustBrowser it comes with the plan ($9.99/mo, unlimited profiles) and answers during the 7-day trial too, so you can script against it before you've paid for anything.

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. This is the fix for my contractor's 1:40 a.m. problem, and almost nobody implements it until after it bites them.

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 your problem. You are.

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 or GET /health 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. Every antidetect browser API has one. 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's genuinely funny to watch in a log file, once.

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. I wrote about two hundred lines of bespoke queue machinery before a coworker just pointed at p-limit and said nothing, which stung more than if he'd said something.)

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 identity an antidetect browser maintains: fingerprint config, cookies, local storage, history, proxy binding. The unit everything else is about.

Session persistence — whether that state survives a restart. If your cookies reset every launch, your aged profile isn't aged. It's cosplaying.

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 antidetect browser doesn't enforce this, your orchestrator has to. See: 1:40 a.m.

7. Ops vocabulary

Orphaned process — a browser that's still running after the thing that launched it gave up. Eats RAM, holds file locks, shows up in ps aux at 3 a.m. looking smug. Found eleven on a box I'd sworn I cleaned the week before.

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)

Stealth plugin — the patch-it-in-JavaScript approach (puppeteer-extra-plugin-stealth and friends). It works until a detector checks something at the C++ layer, which is the entire reason native engines like our Chromium build exist. Unpopular take: stealth plugins were fine in 2021 and are now mostly a way to feel productive while losing accounts.

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

Device pixel ratio — a fingerprint parameter that leaks constantly through automation because people set viewport size and forget DPR exists. Borderline operator vocabulary, so it didn't make the list. Still catches people.

Quick verdict

If you only internalize one distinction from all of this: headless is a launch mode, antidetect is an engine property, and they have nothing to do with each other. I'd guess a third of the "our profiles got banned" messages I see trace back to someone conflating those two 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 are what actually get accounts killed — not some exotic canvas mismatch.

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.

One caveat before you go: WebDriver BiDi is going to churn some of these definitions over the next eighteen months. I'll update when it does.

Frequently Asked Questions

What's the difference between a headless browser and an antidetect browser in 2026?

Headless describes a launch mode — Chromium running with no visible window, driven entirely over a protocol. Antidetect describes what the engine reports about itself: canvas, WebGL, audio, fonts, timezone, navigator. They're orthogonal. You can run a headless antidetect profile, and plenty of people do. You can also run a headful stock Chromium that gets flagged within a page load. Confusing the two is how teams end up disabling headless mode as a fix and wondering why nothing changed.

Do I need CDP if the antidetect 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?

Honestly, 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. I've watched people do exactly that.

Try JustBrowser

Native Chromium antidetect browser — not extension-based. Real C++ engine patches at the canvas / WebGL / audio / font / screen layer, so 40+ identity parameters are genuine, not faked. REST API 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