Core feature · Developer API

How to use the Local API: one HTTP request launches a profile and Puppeteer attaches to it

There is usually nothing wrong with your script. The problem is that it runs inside a bare browser with no fingerprint, no session and one shared exit for every account. NexBrowser turns the profile layer into a plain API: one local HTTP call launches the profile you name and returns a debugging port, and the framework you already use connects to it. The API ships with the client, costs nothing and has no call cap.

Free download See pricing

The Local API is free with unlimited calls, on the free plan too.

Local APIFree & unlimited

POST http://127.0.0.1:port/browser/start
{ "envId": "Store-US-01" }

200 OK
{ "ws": "ws://127.0.0.1:9222/devtools/...",
  "debugPort": 9222 }

Selenium / Puppeteer / PlaywrightAttach

Call quotaUnlimited

Start with the problem

When automation stalls, the profile layer is usually why

Anyone who has written a scraper or a batch script has hit all four of these, and none of them are about how well the code is written.

The script is flagged the moment it ships

A browser launched by Selenium carries obvious automation markers: the webdriver flag, a missing plugin list, a font and Canvas combination no real user has. The verdict lands before the page finishes loading.

The automation API is sold by tier

Using the API means upgrading, and the upgrade still caps daily calls. Batch jobs die halfway, re-running costs again, and the bill stops being predictable.

Sessions start from zero every time

Each run launches a clean browser with empty cookies, so the script grinds through login, codes and second factors first. Across dozens of accounts, the actual business logic is a small slice of the runtime.

Profiles can only be opened by hand

With no API there is no orchestration: somebody has to open the client and double-click profiles one by one. Nothing runs in CI, and an overnight job still needs a person awake.

Automation should not stall at the API layer

The old way

Automation APIs locked behind a higher-priced plan
Daily call quotas that kill batch jobs halfway through
No real docs — profiles have to be opened by hand
Scripts carrying automation markers get stopped on the first page

With NexBrowser

The Local API is free, with no cap on calls
One request spins up a profile and returns its debugging port
Selenium, Puppeteer and Playwright attach as-is
Fingerprint, proxy and session belong to the profile; scripts hold only business logic

What you get

Everything developers actually ask for

From launching a profile to plugging in an AI agent — all of it driven by code.

Free, with unlimited calls

The API ships with the client at no extra cost and no request cap — the free plan runs full automation too.

Works with the frameworks you use

It hands back a standard debugging port, so Selenium, Puppeteer, Playwright and WebDriver run your existing scripts unchanged.

Manage profile lifecycles in code

Start, stop and check status through the API, so batch jobs can spin profiles up and tear them down on demand.

Wire in AI agents and internal systems

Connect frameworks like browser-use and Playwright MCP, or embed the API in your own back office and CI pipelines.

How to use the fingerprint browser API: one request, one debugging port

The call flow has three steps and three things worth knowing. First, the client listens on a local HTTP port, so the endpoint looks like http://127.0.0.1:port/browser/start and the port number is visible in the client settings. Second, the request body names the profile to launch, and that profile loads its own fingerprint parameters, proxy binding and cookie directory — none of which you configure again in the script. Third, the response returns that profile debugging port and WebSocket address, and from there it is ordinary CDP work.

Lifecycle management runs through the same API: start, close and status calls all exist, so a batch job can spin profiles up on demand and tear them down when it finishes rather than holding windows open. Because the API is free with no call ceiling, starting and stopping profiles inside a loop is perfectly safe — there is no quota waiting to surprise you.

One POST launches the profile you name, with fingerprint and proxy loaded automatically
The response carries the debugging port and WebSocket address for CDP attachment
Start, stop and status all run through the API, so batch jobs manage their own profiles

See how AI agents use this API

Local APIFree & unlimited

POST http://127.0.0.1:port/browser/start
{ "envId": "Store-US-01" }

200 OK
{ "ws": "ws://127.0.0.1:9222/devtools/...",
  "debugPort": 9222 }

Selenium / Puppeteer / PlaywrightAttach

Call quotaUnlimited

Selenium detected, Playwright blocked: the script is rarely the cause

Point Selenium or Playwright straight at a local Chrome and getting stopped is close to inevitable: automation launch flags, the webdriver property, missing plugin and permission lists, a font and Canvas combination that does not match a real user, plus twenty accounts sharing one exit IP and one fingerprint. None of those signals depend on how good your code is — they live in the profile layer.

The Local API splits the responsibilities cleanly. The profile layer looks like a real device: a genuine Chrome core, twenty-odd fingerprint parameters that agree with one another, an isolated data directory, a residential proxy of its own and a session that persists. The script layer only handles business logic — paginate, extract, submit. Existing Selenium or Playwright code barely changes; you simply point the connection at the returned debugging port instead of launching a browser yourself.

Automation markers, fingerprint consistency and exit IP belong to the profile, not the script
A real Chrome core with 20+ consistent parameters and a proxy bound per profile
Existing Selenium and Playwright scripts only change where they connect

See the fingerprint and privacy layer

CanvasOwn noise

WebGL / GPUPer profile

Font listMatched to OS

Timezone / langFollows exit IP

WebRTCPer profile

Audio / screenOwn values

20+parameters

Wire profiles into your own systems, CI and AI agents

Once it is an API, a browser profile becomes an ordinary component of your stack. An internal ticketing system can launch the profile for a given store and run a check when a status changes. A CI pipeline can run end-to-end cases in a real fingerprint profile after each release. A scheduler can start dozens of profiles during off-peak hours to collect data and release them when the job is done.

AI agents take the same route. Frameworks like browser-use and Playwright MCP already drive a browser through a debugging port, so pointing them at the port NexBrowser returns moves the agent from a bare browser into a real profile with a fingerprint, a proxy and a live session. For the parts nobody wants to write code for, the built-in no-code RPA covers the same profiles, and the two approaches mix freely.

Internal tools, schedulers and CI pipelines call the API without anyone opening the client
browser-use, Playwright MCP and similar agents attach through the debugging port
No-code RPA covers the rest, running on the same set of profiles

Prefer no code? Use RPA

You

Update the listing titles in these 24 stores with the new template and send me a list.

1Open each authorized profile

2Go to the product list page

3Update title and price by template

4Screenshot and summarize

Generated flowReusable

ScopeAuthorized only

Download the client and connect your first profile

The Local API is free with unlimited calls, available on the free plan as well.

Free Download

Two snippets: launch a profile and attach with Puppeteer

Here is one complete round trip: fetch the local endpoint to launch a profile, read the debugging port from the response, then connect Puppeteer to it. Selenium, Playwright and WebDriver differ in syntax only.

Node.js exampleFree & unlimited

import puppeteer from 'puppeteer-core'; // 1) start the profile — its fingerprint, proxy and cookie directory load automaticallyconst res = await fetch('http://127.0.0.1:PORT/browser/start', {  method: 'POST',  headers: { 'Content-Type': 'application/json' },  body: JSON.stringify({ envId: 'Store-US-01' }),});const { debugPort } = await res.json(); // 2) attach to the debugging port it returns — the script only holds business logicconst browser = await puppeteer.connect({  browserURL: 'http://127.0.0.1:' + debugPort,  defaultViewport: null,});const [page] = await browser.pages();await page.goto('https://seller.example.com/orders');

PORT is the local API port shown in the client settings and envId is the profile ID from your profile list. Selenium and Playwright work the same way — point them at the returned debugging port.

What the API covers

Start a profileReturns a debug port

Close a profileFrees the window

Query statusRunning or not

Call quotaUnlimited

Fingerprint parameters, proxy binding and cookie isolation are handled at the profile level, so scripts configure none of it. Batch jobs can open profiles on demand inside a loop and close them when finished.

Three steps to put a browser profile inside your code

The typical call flow is just three steps: launch the profile, take the debugging port it returns, then attach with the framework you already know. Fingerprints, proxies and cookie isolation are handled at the profile level, so your scripts only deal with business logic.

Step one: call the local endpoint to launch a specific profile, with its fingerprint and proxy settings loaded automatically.

Step two: the response gives you that profile debugging port — nobody has to open a window in the client.

Step three: connect Selenium, Puppeteer or Playwright to the port and run your existing scripts as usual.

FAQ

Local API FAQ

Is the Local API free? Are there call limits?

It is completely free and there is no cap on the number of calls. The API ships with the Windows client and is available on the free plan as well, so you never buy a separate tier just to automate, and a batch job never runs into a quota halfway through.

Which automation frameworks are supported?

The API returns a standard debugging port, so Selenium, Puppeteer, Playwright and WebDriver can all take over a profile directly. Existing scripts usually need no rewriting — point the connection at the port you get back and the business logic stays exactly as it is.

Selenium keeps getting detected. Does the Local API fix that?

Most detection happens in the profile layer: automation launch flags, missing plugins and fonts, contradictory fingerprint values, many accounts behind one exit IP. The Local API hands your script a profile with a real Chrome core, consistent parameters and its own proxy, so those signals read normally. Pacing your actions so they do not look mechanical is still up to you.

Can I connect an AI agent?

Yes. Agent frameworks such as browser-use and Playwright MCP attach to a NexBrowser profile through its debugging port, so the agent operates inside a real environment with its own fingerprint and proxy. That makes it practical to hand multi-account workflows to AI.

What if I do not want to write code?

Use the built-in no-code RPA instead. It offers a drag-and-drop flow builder, recorded steps, scheduling, retries and variables, and runs the same flow across many profiles at once. Teammates who do not code can set up their own tasks, and the two approaches work side by side.

Have other questions? We're here to help anytimeContact Support →

Keep reading about the developer stack

Ready to manage every account profile in one place?

Install in 3 minutes. 10 free windows on sign-up, no credit card.

Free Download for Windows

Already have an account? Sign in to the client to sync all profiles.