Antidetect Browser With Automation API: A Practical Guide

Most buying guides for antidetect browsers spend their word count on fingerprints — canvas noise, WebGL vendor strings, font enumeration, the usual checklist. That work matters, and it is also the part that every serious vendor has now solved to roughly the same standard. What actually separates a tool you outgrow in a quarter from one you build a business on top of is the automation surface: whether you can create, launch, drive and tear down profiles from code, and whether doing so leaves marks that the target site can see.

This article is about that second half. It is written for people who have already accepted the premise — if you are still working out what these tools are, start with what an antidetect browser is and how it works and come back. Everything below assumes you have twenty, two hundred or two thousand profiles and a growing suspicion that clicking through them by hand is not a plan.

The API becomes the product somewhere around fifty profiles

There is a threshold every multi-account operation crosses. Below it, manual work is fine: you open a profile, do the thing, close it. Above it, the arithmetic turns against you. Fifty profiles that each need a two-minute daily warm-up is one hundred minutes of clicking, every day, forever, and that is before anything goes wrong.

The first instinct is to hire. The second, better instinct is to script. And that is the moment you discover which antidetect browser you actually bought. Some tools expose a rich HTTP interface and treat automation as a first-class use case. Some expose a launch endpoint and wish you luck. Some have a REST API that can create profiles but cannot tell you whether one is currently running, which sounds like a footnote until your orchestrator opens the same profile twice on two machines and burns the session.

So the question is not really does it have an API. Almost everything has an API now. The question is what kind, how honest it is about what it is doing under the hood, and whether the automation path is as stealthy as the manual one. That last point is where most of the damage happens, and it is where I want to spend the most time.

Three different things vendors call an "automation API"

When a product page says automation API, it means one of three architectures. They are not interchangeable, they fail in different ways, and a lot of buyer confusion comes from comparing a profile API against a live-control API as if they were the same feature.

1. The profile management API

This is CRUD over your workspace. Create a profile with a given fingerprint, attach a proxy, set a name and a group, update it, delete it, list what exists. It never touches a running browser.

You need this the moment your profile count outgrows the UI. It is how you provision two hundred accounts from a spreadsheet, rotate a whole group onto a new proxy pool after a subnet goes bad, or reconcile your internal database against the browser's state on a schedule. It is also the easiest API to build, which is why it is the one everybody has.

The quality signals here are boring and important: is create idempotent (can you re-post the same profile without minting a duplicate), can you supply your own ID so your CRM row and the browser profile share a key, does delete leave a tombstone so a later sync cannot resurrect it, and does the list endpoint page properly with a total count you can verify against. Every one of those sounds pedantic until you have eleven hundred profiles and no idea which four hundred are duplicates from a retried import.

2. The launch API — you get a CDP endpoint and you are on your own

The second pattern: you call something like POST /profile/{id}/start, the browser launches with its fingerprint applied, and the response hands you back a WebSocket URL. From there you connect Puppeteer or Playwright and drive it yourself, exactly as you would drive a normal Chrome.

This is enormously flexible. Your team already knows Playwright. Your existing test helpers work. You can do anything the Chrome DevTools Protocol allows, which is nearly everything.

It is also the pattern that quietly gets people flagged, for reasons I will get into in the next section. In short: attaching a full automation framework to a browser changes the browser's observable behaviour, and the antidetect layer cannot protect you from tells that your own client introduces after launch.

3. The live control API — the vendor drives the page for you

The third pattern keeps the driving inside the tool. You send POST /profiles/{id}/click with a selector, or /type, or /goto, and the tool performs the action against the running browser using whatever internal mechanism it considers safe. You never hold a CDP connection yourself; you speak plain HTTP.

The trade is expressiveness for safety. You lose the long tail of CDP features. You gain a driving path that the vendor controls end to end and can keep clean — no automation framework handshake, no framework-specific artefacts, no accidental Runtime.enable. For the great majority of real work (log in, navigate, fill a form, read a value, screenshot, capture network traffic) that trade is a bargain.

The strongest products offer all three, and let you choose per profile. That is the shape to look for in an antidetect browser with automation API support: profile CRUD for provisioning, a live control API as the default driving path, and a raw CDP escape hatch for the ten percent of cases that need it.

Why automation is where antidetect browsers usually get caught

Here is the uncomfortable truth about this category. A well-built antidetect profile, opened by hand and used by a human, is very hard to distinguish from a real machine. The same profile, driven by an off-the-shelf automation script, can be trivial to spot — and the fingerprint had nothing to do with it.

Detection vendors do not need to break your canvas hash. They watch for behaviour and for protocol artefacts, and automation produces both in quantity.

The webdriver flag and the launch arguments

The obvious one first. navigator.webdriver is a standardised property — MDN documents it as reporting whether the user agent is under automation control — and it flips to true when the browser is launched with the automation switches that Selenium and, by default, Puppeteer use. Any patching library will tell you it has handled this. Most have. But the flag is only the first layer, and the fact that a tool advertises webdriver: false tells you approximately nothing about the rest.

More interesting is what else those switches do. --enable-automation does not just set a boolean; it changes password-manager behaviour, disables certain prompts, and adds an infobar. A page cannot read the infobar, but it can read side effects of the configuration changes. The correct approach is not to launch with automation switches and then paper over the flag — it is to never launch with them at all, and open a debugging port instead.

The Runtime.enable tell

This is the one that catches sophisticated setups, and it deserves more attention than it gets.

The CDP Runtime domain is how automation frameworks evaluate JavaScript in a page. Puppeteer and Playwright enable it by default on every frame, because their entire API surface — page.evaluate, element handles, most locators — depends on it. Enabling the domain is observable from inside the page: it changes the behaviour of certain console and error-serialisation paths in ways a detection script can probe for cheaply. The details shift between Chromium versions, which is exactly why chasing individual patches is a losing game.

The robust answer is architectural: drive the page without ever enabling Runtime. You can do a surprising amount with only DOM, Input, Page, Network and Target — resolve a node from a selector through DOM.querySelector, get its box model, dispatch a real input event at those coordinates. No script evaluation, no Runtime, no tell. It is more work to build than page.click(), which is precisely why it should be your vendor's job rather than yours.

If you take one technical criterion away from this article, make it that one: ask whether the tool's driving path enables the Runtime domain, and if so, when. A good answer names the specific exceptions (an explicit eval action, perhaps a <select> helper) and flags them in the response so you know you spent the risk.

Synthetic events are not trusted events

Every DOM event carries an isTrusted property. MDN is unambiguous: it is true when the event was generated by user action and false when created or modified by a script. A click produced by element.click() in page JavaScript is false. A click produced by CDP's Input.dispatchMouseEvent goes through the browser's own input pipeline and is true, because as far as Chromium is concerned the click came from the embedder, not from the page.

That distinction is the whole ballgame for login flows and payment pages, which routinely check it. Any automation API worth using dispatches through the input pipeline at real screen coordinates rather than calling into the page. Ask the vendor directly. If the answer involves injecting a script that calls .click(), you are buying a liability.

Timing that no human produces

The subtler category. Humans hesitate. They move the mouse in curves, overshoot the target, read for two seconds before typing, mistype and correct. A script that fills a fourteen-character password in fourteen milliseconds with zero pointer movement has produced a signal no fingerprint can hide.

Behavioural scoring is now standard on the platforms that care, and it compounds: a slightly-off fingerprint plus perfectly regular timing plus a datacentre IP is a confident block, where any one of the three alone would have passed. Good automation APIs expose per-character typing delays, human-ish mouse paths and configurable waits. Good operators use them even when it feels slow, because the alternative is a re-verification queue.

For the broader picture of what is being measured and why, browser fingerprinting explained covers the surface area, and the EFF's Cover Your Tracks is still the clearest hands-on demonstration of how few bits it takes to make a browser unique.

A comparison of the three automation surfaces

The honest recommendation: default to the live control API, provision with the profile API, and keep the CDP escape hatch for the cases that genuinely need it — then treat every use of it as a deliberate risk decision rather than a habit.

Local API versus cloud relay: pick the boundary on purpose

There is a second architectural fork that buyers often miss. Where does the API live?

Local API. The tool runs on your machine and exposes HTTP on localhost. Your scripts talk to 127.0.0.1. Latency is zero, nothing leaves the machine, and the API is available with the network down. The limitation is obvious: your orchestrator has to run on the same box, or you have to expose a port, which you should not do casually.

Cloud relay. The vendor's cloud accepts your API call and forwards it to an agent process running on your PC, which then calls the same local endpoints. You get to drive machines from anywhere — a CI runner, a serverless function, a colleague's laptop — without opening ports or managing tunnels.

The relay pattern is the right answer for distributed teams, and the detail that determines whether it is safe is authentication. The relay agent must forward the calling account's credentials to the local API, not act as an unauthenticated trusted client. If it does not, then anyone who can reach the relay can drive every profile on that machine regardless of which account owns them. That is a real bug class, not a theoretical one, and it is worth asking about explicitly when you evaluate. Teams thinking about this at organisational scale should also read browser profile management best practices for teams, which covers the permission side of the same problem.

What a real integration looks like

Abstractions are easy to nod along to, so here is the concrete shape of a working daily job — account warm-up across a group of profiles. The endpoint names below follow the pattern most local APIs use; adapt to yours.

Step one: resolve the work list. GET /api/profiles?group=warmup&limit=200&offset=0, paging until you get a short page. Do not assume one request returned everything. If the API gives you a total count header, compare it against what you collected and fail loudly if they disagree — a silent short read is how half your accounts quietly stop being warmed.

Step two: check what is already running. GET /api/running. Opening a profile that is already open on another machine is the single most destructive mistake in this category, because two live sessions write conflicting cookies and the last one to close wins. If your tool offers a cross-machine open lock, use it. If it does not, build one yourself with a shared table and a lease.

Step three: launch, and wait for health rather than for a timer. POST /api/profiles/{id}/launch returns quickly, but the browser is not usable the instant the process spawns. Poll for a real readiness signal — a debug port that answers, a first tab that exists — rather than sleeping for a hopeful five seconds. Chromium re-parents its own process on startup, so a naive PID check can report success for a browser that never drew a window.

Step four: drive. A warm-up loop is unglamorous: POST /goto to a plausible destination, POST /wait for a selector, POST /scroll a couple of times with pauses, maybe POST /click a link, POST /get to confirm you are still logged in. Between actions, sleep for randomised human intervals. Two to six seconds is a reasonable band; identical sleeps are their own signal.

Step five: verify session state before you close. Read something that only an authenticated session can see. If it is missing, you have learned something important — do not just log success because no HTTP call returned an error.

Step six: stop cleanly. POST /api/profiles/{id}/stop. The stop path is where cookies and local storage get captured back into the profile, so a killed process instead of a clean stop can cost you the session. Give it time to finish.

Step seven: record. Per profile, log the outcome, the proxy used, the duration and any anomaly. When something breaks in six weeks, this log is the only thing that will tell you whether the problem is one account, one proxy subnet or one platform changing its rules.

The whole job is maybe 150 lines. The value is not in the code, it is in the discipline: verify, do not assume; wait for signals, not timers; and treat every profile as a session that can be destroyed by carelessness, because it can.

Concurrency: what actually limits you

Everyone asks how many profiles they can run at once. The honest answer is that RAM is the binding constraint, not the API.

A real Chromium process with its own user-data directory costs several hundred megabytes once a page is loaded, more with heavy sites. Low-memory modes help — disabling site isolation and capping the V8 heap can push you toward roughly five instances per 4 GB — but you are still budgeting in gigabytes, and you cannot economise your way out of it, because sharing memory between profiles means sharing state between profiles, which defeats the entire point.

So plan capacity in tiers. A 16 GB workstation comfortably runs a dozen or so profiles simultaneously; that is not the same as managing a dozen profiles, since a well-designed job opens and closes them in waves. Two hundred profiles on a nightly cycle with fifteen concurrent and a three-minute visit each is about forty minutes of wall clock. That is a perfectly ordinary workload for one machine.

Two scheduling notes that save real pain. First, stagger the launches. Fifteen browsers starting in the same second will thrash the disk and some will time out. Ramp them in over thirty seconds. Second, watch out for occlusion throttling: Chromium aggressively de-prioritises windows it believes are hidden, so a stack of overlapping profile windows can stall mid-automation for no visible reason. A tool built for this launches with anti-throttle flags on by default. If yours does not, your "random" hangs have a cause.

Proxies and the state problem

Automation multiplies proxy mistakes. A human notices when a page loads in a different language or a captcha appears; a script marches on and posts the form.

Bind the proxy to the profile, not to the run. The proxy is part of the identity — changing the exit IP on an established account is one of the loudest signals available, far louder than any fingerprint detail. If a proxy dies, the correct action is usually to pause the profile until you have a replacement in the same city, not to run it through whatever is free.

Check geographic consistency before you drive. Timezone, locale and language should agree with the exit IP, and if the tool derives them from the proxy automatically, verify it did. A US residential IP presenting Europe/Kiev is a mismatch that costs nothing to catch and a lot to ignore.

And resist the temptation to treat captchas as a fingerprint problem. In nearly every case a captcha is the IP's reputation talking, not your canvas hash. If one subnet produces challenges across ten otherwise-healthy profiles, the subnet is the variable. Web scraping without getting blocked goes deeper on proxy hygiene and request pacing, and most of it applies directly to account automation too.

Selector-free automation, and why it matters more than it sounds

A quiet advantage of the better live-control APIs: OCR-driven actions. Instead of click("#submit-button"), you say find the text "Continue" on screen and click it.

This is not a gimmick. Selectors break constantly — platforms ship obfuscated class names that change weekly, and A/B tests mean two accounts see two different DOMs on the same day. An OCR click reads the rendered screenshot, locates the text, and dispatches a trusted click at those coordinates. It survives markup churn entirely, and because it never touches the DOM it also never needs the Runtime domain.

It is slower and it is not right for everything — you would not scrape a table with it. But for the fragile parts of a flow, the login button and the consent dialog and the Continue that moved, it converts a weekly maintenance chore into something that just keeps working.

Mistakes that cost people accounts

A short list, all of them things I have watched happen.

Running the same profile in two places. Covered above, and still the top cause of lost logins. Two machines, both syncing sessions, both convinced they have the current cookies. One of them is wrong and it overwrites the other.

Treating an API error as the only failure mode. HTTP 200 means the click was dispatched, not that it did anything. Verify state after every meaningful action.

Perfectly regular scheduling. Twenty accounts that all check in at 09:00:00 UTC, seven days a week, are twenty accounts with a shared signature. Jitter your schedule by tens of minutes and skip days at random.

Copying a profile directory to clone an identity. Fingerprints are usually bound to their data directory by design, and copied cookie jars mean two profiles carrying the same session tokens. Clone through the API, which mints fresh identity material.

Automating the platform that punishes it hardest without adjusting pace. Different platforms have wildly different tolerances; social networks in particular score behaviour aggressively. If your target is Meta's ecosystem, managing multiple Facebook accounts safely is worth reading before you script anything.

Skipping the audit trail. When something goes wrong at scale, the question is always what changed. Without per-request logs — which profile, which caller, which proxy, what response — you are guessing.

How Dual Login handles this

Dual Login was built around the automation path rather than having one bolted on, and the design decisions follow directly from the problems above.

The fingerprint is applied natively, in the engine, not by injecting JavaScript into pages. That means there is no injected script for a detector to find, no timing gap on page load before the spoof takes effect, and the same identity reaches Web Workers and iframes, which script-based approaches routinely miss.

The default launch path is stealth: the engine is spawned directly, with no automation framework attached and no --enable-automation. A debugging port is opened so automation and cookie capture still work over a brief raw connection, but nothing holds a persistent framework session against the browser. navigator.webdriver stays false because the browser was never launched as an automated one.

The driving layer speaks raw CDP with the Runtime domain switched off — DOM, Input, Page, Network and Target only. Clicks and keystrokes go through the input pipeline, so they arrive as trusted events. Three actions can opt into script evaluation when you genuinely need it (eval, select, and a live get), and each one flags itself in the response so the risk is visible rather than silent.

Every action is a plain HTTP call against POST /api/profiles/{id}/{action} — navigation, tabs, mouse and keyboard, screenshots, OCR actions, network capture. The same call works locally and through the cloud relay, which forwards your account's credentials to the local agent so relayed calls stay account-scoped. Sessions are captured every twenty seconds and on stop, so a crash costs you seconds rather than a login, and profiles carry their cookies between machines through the sync layer.

And because it runs on your hardware, per-profile RAM is your only real ceiling. There is no per-seat automation surcharge and no queue behind someone else's cloud capacity.

If you are cross-shopping, the top antidetect browsers compared puts the automation surfaces side by side, and the Multilogin alternative comparison covers the pricing model differences that matter most at scale.

FAQ

Can I use Puppeteer or Playwright with an antidetect browser?

Usually yes — most tools return a CDP WebSocket URL when you launch a profile, and both frameworks will connect to it happily. The caveat is that both enable the CDP Runtime domain by default on every frame, which is independently detectable regardless of how good the fingerprint is. If you use them, connect to an existing browser rather than launching one, keep Runtime usage to a minimum, and prefer the tool's own driving API for anything touching a login or a payment page.

Does using an automation API make my profiles easier to detect?

It can, but the API itself is rarely the problem. Detection comes from three things automation tends to introduce: automation launch switches, an attached framework that enables script evaluation, and inhumanly regular timing. An API that dispatches trusted input events without enabling the Runtime domain, driving a browser launched without automation switches, is essentially indistinguishable from a human on the protocol level — at which point your remaining exposure is behavioural, and you control that with pacing.

How many profiles can I automate at once?

Memory decides, not the API. Budget several hundred megabytes per running profile; with a low-memory mode you can get to roughly five per 4 GB of RAM. A 16 GB machine handles a dozen or so concurrently, which is usually plenty because well-written jobs cycle profiles in waves rather than holding them all open. Stagger launches over tens of seconds so you do not thrash the disk on startup.

What is the difference between the profile API and the live control API?

The profile API manages records — create, update, delete, list — and never touches a running browser. The live control API acts on a browser that is already open: navigate, click, type, screenshot, read. You need both, and they are frequently confused in marketing copy. A tool that advertises a REST API may only have the first one.

Should I run the automation API locally or through a cloud relay?

Locally if your orchestrator lives on the same machine — it is faster, it works offline, and nothing leaves the box. Through a relay if you are triggering runs from CI, a server, or a distributed team, since that avoids exposing a port. The security question to ask about any relay is whether it forwards the calling account's credentials to the local API; if it acts as an unauthenticated trusted client, one account can drive every profile on the machine.

Can I automate account creation and warm-up safely?

Warm-up automates well: browsing, scrolling, reading, occasional interaction, spread across randomised times. Creation is much riskier, because signup flows carry the heaviest behavioural and device scrutiny of anything a platform runs, and a failed batch can taint the proxies and the fingerprints you used. The common pattern is to create by hand or in very small, slow batches, then automate everything afterwards.

Wrapping up

Choose an antidetect browser the way you would choose a database: not on the demo, but on what happens at ten times your current volume. The fingerprint gets you in the door. The automation API is what determines whether year two is a business or a maintenance burden.

The questions worth asking a vendor are short. Does the driving path enable the CDP Runtime domain, and where? Are dispatched clicks trusted events? Is the browser launched with automation switches? Does the same API call work locally and remotely, with the same shape? Can I see what is running, right now, across every machine? Vendors who have thought about detection answer these immediately and specifically. The rest change the subject to fingerprint quality.

If you want to try the approach described here — native fingerprints, a stealth launch with no framework attached, and a Runtime-free HTTP automation API that behaves identically on your desk and through the relay — Dual Login runs on your own hardware and the automation surface is included rather than upsold. Spin up a handful of profiles, point a script at them, and check the result on a detection page yourself. That is the only benchmark that counts.