Anti detect browser API: 3 call shapes compared

An anti detect browser API comes in three call shapes. A local REST API on a desktop profile manager fits a person who manages many long-lived profiles. A hosted browser you drive over CDP with Playwright or Puppeteer fits code that needs a held session, and a page-fetch API fits jobs where one request returns one page and keeps nothing.

The three shapes of anti detect browser API need different code and bill in different units. That matters if you build scrapers, price monitors or test automation and have to choose one.

After reading, you can pick the shape that fits your job, run a connection script against it, estimate what your workload will cost, and know where the limits sit.

Key Takeaways

• Only Chromium-family clients attach over CDP, and that path has lower fidelity than Playwright’s own protocol connection.
• Set connect timeouts above the cold start, and treat close code 4007 as a bad location code.
• Per-call plans charge every retry, while per-page plans charge only for pages that come back.
• Hosted sessions keep cookies only while the socket is open, so persist state in your own code.

What is an anti detect browser API?

An anti detect browser API is a programmatic way to control a browser that presents a managed fingerprint. The three shapes differ in who operates the browser and what state survives between calls.

A local REST API runs inside a desktop app on your own machine. You call it with an API key, and it automates what a person does in the app. The buyer is a person or team that hand-manages many long-lived profiles.

The getantidetect Automation API docs list an “Auth & key model” and then profile management, launching a saved profile and session management.

A hosted browser over CDP is one you reach by opening a WebSocket and attaching Playwright, Puppeteer or any CDP client. The buyer is a developer whose code needs a held session.

A page-fetch API takes parameters and returns content, for buyers who need pages and no session. Wayfern’s Web Data API is this shape, and Apify lists its Stealth Anti-Detect Browser Gateway as “Pay per page.”

Call shape	Who operates it	State kept	Fits which job
Local REST API	A person on their own machine	Saved profiles on disk	Many long-lived identities
Hosted browser over CDP	Your code, on hosted infrastructure	Held while the socket is open	Login, forms, multi-step flows
Page-fetch API	Your code, one request at a time	None between calls	Single public pages

Take a login followed by a dashboard read. Each shape handles it differently. With a local REST API, you launch a saved profile through a localhost call, and its cookies are already there. With a hosted CDP browser, you connect once and run both steps on the same socket.

With a page-fetch API, each call is separate. As Wayfern’s sessions page puts it, a request/response endpoint “returns one page and keeps nothing.”

If a person manages many long-lived profiles by hand, our Wayfern vs Multilogin comparison covers when a desktop profile manager is the better purchase.

How do you connect to an anti detect browser API over CDP?

You connect to a hosted anti detect browser API over CDP by opening a WebSocket to wss://api.wayfern.com/ws with a link token, then passing that URL to Playwright or Puppeteer. There is no SDK to install.

1. Mint a link token per project and store it in the env var WF_TOKEN, out of source control. The Wayfern API reference lists the connection cap, optional expiry and revocation.
2. Build the URL. Start with wss://api.wayfern.com/ws?token=LINK_TOKEN and add country, region, session, width and height only when you need them.
3. Pick a Chromium-family client. Playwright’s BrowserType docs say connectOverCDP() is “only supported for Chromium-based browsers”, and the hosted browser is Chromium only, so Firefox and WebKit builds can’t attach.
4. Run the script. This Playwright example opens a page and prints its title:

import { chromium } from "playwright";

const url = `wss://api.wayfern.com/ws?token=${process.env.WF_TOKEN}&country=US`;
// The session starts when this socket opens.
const browser = await chromium.connectOverCDP(url, { timeout: 120000 });
const page = await browser.contexts()[0].newPage();
await page.goto("https://example.com");
console.log(await page.title());
await browser.close();

The timeout option is raised because the first connection waits for the browser to start. Use contexts()[0], the context that already exists, instead of creating a new one.

5. Use Puppeteer if you prefer it. Puppeteer’s connect reference says puppeteer.connect() attaches “to an existing browser instance” through browserWSEndpoint:

import puppeteer from "puppeteer-core";

const browser = await puppeteer.connect({
  browserWSEndpoint: `wss://api.wayfern.com/ws?token=${process.env.WF_TOKEN}`,
});
const page = await browser.newPage();
await page.goto("https://example.com");
console.log(await page.title());
await browser.disconnect();

What the anti detect browser API sends back

The first message back on the socket is a JSON connected message that carries a connectionId, and everything after it is plain CDP, according to the Wayfern API reference. Playwright and Puppeteer consume that handshake for you, so you only see it if you open the socket with a raw WebSocket client.

Playwright’s docs also warn that this attach path is “significantly lower fidelity than the Playwright protocol connection”. Expect some advanced Playwright features to behave differently over CDP.

Which detection signals does an anti detect browser API handle?

An anti detect browser API handles three kinds of detection signals: automation flags, clues about the machine’s graphics, and consistency across everything a site can see in one visit.

Automation flags are the cheapest check, because reading one costs a site a single line of script. MDN says navigator.webdriver “indicates whether the user agent is controlled by automation,” and the WebDriver specification defines it as “Returns true if webdriver-active flag is set, false otherwise.”

Runtime.enable is a CDP call that automation libraries send, and some pages look for its side effects.

One flag rarely decides alone. Sites weigh several signals, and the outcome shifts when they agree.

Headless is not one browser. Chrome’s headless documentation says the older separate headless implementation now ships as chrome-headless-shell, so “headless Chrome” can mean two different browsers.

The WebGL renderer string describes the graphics hardware. MDN describes WEBGL_debug_renderer_info as exposing “information about the graphics driver.” On a server with no GPU, Chromium can fall back to SwiftShader, a “CPU-based implementation of the Vulkan graphics API.”

The renderer string then names software rendering instead of a graphics card, which a site can compare against the platform the browser claims.

Fingerprint, exit IP, timezone and cookies have to describe one visitor. As Wayfern’s sessions page notes, a cookie issued to one IP and replayed from another is an easy signal for a site to read.

Identity built into the browser or injected by script

A script injected into your pages overrides properties one at a time, and any property it misses can disagree with the ones it changed.

Wayfern applies the browser identity inside its own Chromium build, so no script runs in your pages. Viewport shows the difference. Set width and height on the /ws URL (500 to 3600 by 400 to 1900 CSS pixels) and the real window is resized:

wss://api.wayfern.com/ws?token=LINK_TOKEN&width=1440&height=900

Nothing is emulated, so media queries, outerWidth, outerHeight and screen.* all come from the same window and stay consistent with each other.

How do anti detect browser API sessions, sticky exits and limits work?

A Wayfern session starts when you open the CDP WebSocket, lives as long as that socket stays open, and answers bad parameters or exhausted limits with a refusal instead of a guess.

The API reference says opening the socket starts the session.

Anything the next run needs has to be saved in your own code before the socket closes.

Set your connect timeout well above the browser’s start time.

The exit is part of the connection URL, and the default is a datacenter exit. For a residential exit you pass country, region, city and isp, plus a sticky session id that holds one residential IP for a whole flow. To use your own proxy, pass proxy=own.

Wayfern’s sessions page says codes are checked against a live catalog, and an unknown location is refused with close code 4007 instead of falling back. Connect with a country code that isn’t in the catalog and log the close event:

import WebSocket from "ws";
const ws = new WebSocket("wss://api.wayfern.com/ws?token=LINK_TOKEN&country=XX");
ws.on("close", (code) => console.log("closed", code)); // 4007

Two caps bound concurrency, according to the API limits page: each link token has a connection cap from 1 to 100, and your plan sets how many pages can be open at once. The same page lists the default API rate limit and per-route limits.

Billing refuses work instead of running into debt. Wayfern’s pricing page says that at zero credits there is a hard stop: calls are refused and open sessions are closed. No overage accrues unless you turn on auto top-up, which is off by default.

How is an anti detect browser API priced?

An anti detect browser API is billed in one of four units, and each unit rewards a different workload.

Billing unit	What you pay for	What drives the bill	How to estimate
Per call	Each launch or request	Attempts, including retries	Target pages times expected attempts
Per successful page	Each page returned	Pages that succeed	Count of target pages
Per session or concurrency tier	Parallel capacity	Pages open at once	Peak parallel pages
Per open-page hour plus bandwidth	Time a page stays open, plus residential GB	Seconds open, GB through the exit	Pages times seconds open, plus GB

Per-call pricing charges every attempt, so a retry costs the same as a first try. The getantidetect API reference lists “₩5 per call”, and the Apify gateway listing prices “from $2.00 / 1,000 actor run initializations”.

Wayfern’s Web Data API charges per page. Wayfern’s pricing page says every response returns the exact credits charged, and failed Web Data work isn’t billed.

Wayfern plans differ in credits, concurrency and seats, and one credit balance covers browser, Web Data, Search and captcha. For a concurrency tier, size by the peak number of pages you need open at once.

Wayfern’s browser is metered per open-page hour, per second, with a 60-second minimum per page.

To estimate an open-page-hour bill, multiply pages by seconds open, divide by 3,600, then add the gigabytes through a residential exit. If 1,000 pages each stay open 20 seconds, each bills as 60 seconds, so the total is about 16.7 open-page hours. Apply the published rates in the monthly cost estimator on the same pricing page.

Match the billing unit to the job:

• Per call fits one-off launches of a local identity.
• Per successful page fits fetch jobs that need one page back.
• A concurrency tier fits steady parallel load.
• Open-page hours fit multi-step flows that hold a page open.

What does a hosted anti detect browser API not do?

A hosted anti detect browser API like Wayfern’s leaves out several things a desktop tool offers, and it runs only Chromium. Wayfern’s comparison with Multilogin states the first limit plainly: “The honest catch: Wayfern has no customer-facing persistent profiles at all.”

• No named profiles, no saved cookie jars, no cookie import or export. Save and restore cookies and storage in your own code between runs.
• No per-vector fingerprint switches for customers.
• No mobile device emulation: the browser presents a desktop device, and phone viewport sizes are not offered.
• No downloadable binary for self-hosting.
• No free tier or trial. The cheapest self-serve options are the Developer plan or a credit pack, listed on the pricing page.

If you hand-manage many long-lived profiles and want per-vector control, buy a desktop profile manager such as Multilogin. The Multilogin comparison lays out where each one fits.

Don’t use an anti detect browser API for fraud, account abuse, credential stuffing, or collection that ignores a site’s terms or the law.

No outcome against an anti-bot system is guaranteed, so test against your own targets before you commit budget.

How do you test an anti detect browser API against your own targets?

You test an anti detect browser API by running one short flow against your own targets on every candidate and recording what each signal check and each page returns. Pass rates depend on the target site, so only your own runs give you a number you can use.

1. Read navigator.webdriver in the page context, not from your driver, and record the value.
2. Read the WebGL renderer: request the WEBGL_debug_renderer_info extension, read the unmasked renderer string, and look for a software-rendered string on a GPU-less server.
3. Compare timezone, language and window values with the exit’s location: check Intl.DateTimeFormat().resolvedOptions().timeZone, navigator.language, window.outerWidth and screen.width against the exit country.
4. Hold the session steady. Use a sticky session id (the API reference lists the parameters), load three or four pages in a row, and confirm the cookies, local storage and exit IP don’t change between them.
5. Run the same flow on each candidate. Record the outcome per target, including how failures appear: a challenge page, an empty result, a redirect or a closed socket.

Add the cost of each candidate to the record. Compare the credits or charge each run reports, so you can price a completed flow instead of an attempt.

Frequently asked questions

Does an anti detect browser API work with Playwright or Puppeteer?

A hosted anti-detect browser accepts a standard CDP WebSocket, so Playwright’s connectOverCDP() and Puppeteer’s puppeteer.connect() both work without an SDK. Wayfern’s sessions page documents the flow: you open wss://api.wayfern.com/ws?token=LINK_TOKEN, and the session starts when the socket opens.

What’s the difference between an anti detect browser and a scraping API?

A scraping API takes a URL and returns one page, keeping nothing between calls. An anti-detect browser gives you a live browser, so multi-step jobs like logins and forms stay in one session.

Does an anti detect browser API keep cookies between runs?

Only while the socket is open. Wayfern’s Multilogin comparison says Wayfern has no named profiles, no cookie import and no cookie export, so you save and restore cookies and storage in your own code between runs. A desktop profile manager fits long-lived identities better.

Can an anti detect browser API emulate mobile devices or run Firefox?

Wayfern can’t do either. Wayfern is hosted anti-detect Chromium, so there’s no Firefox. The API reference says setting width and height on the URL resizes the real window, and nothing is emulated, so the browser doesn’t present itself as a phone.

Which anti detect browser API should you try first?

If code is your operator, try a hosted CDP anti detect browser API first. Start by deciding who operates the browser: a person with long-lived profiles, or your code.

This week, run the connection script and the signal checks on one real target. Then estimate your monthly workload on the Wayfern pricing page, using the billing unit that matches your job.

Before you scale, plan for the cold start, your concurrency cap and the zero-credit stop. Nothing runs on credit you did not buy.

To begin, get a link token from the quickstart in the Wayfern docs, connect Playwright with connectOverCDP() and run your own target through it. Your own run gives you the only success number worth trusting.

Sources

API Reference — Antidetect Browser — Antidetect · Stealth Anti-Detect Browser Gateway API · Apify · Anti-Detect Browser Sessions over CDP | Wayfern · BrowserType | Playwright · Puppeteer.connect() | Puppeteer · API Reference - CDP, Web Data & Search | Wayfern · Pricing - Credits for Browsers & the Web Data API | Wayfern · Wayfern vs Multilogin: anti-detect browser comparison. Every other source is linked where the article cites it.