Automating Dolphin{anty}: What the API Can Do, and What It Can't Reach

Two things are true about the Dolphin Anty API and they pull in opposite directions.

It is one of the better-documented anti-detect browser APIs on the market — real endpoints, real payloads, working code samples in four languages, a published rate limit. Their own users say so; one review on their homepage praises support for sending "a working piece of code" when someone was stuck, and notes that many competitors do not have adequate API documentation at all.

And it is an API about browsers. Everything it can address is a browser object. That is not a limitation anyone should complain about — it is the definition of the product. But it draws a very clean line, and the line is the most useful thing in this article.

Quick answer: the Dolphin Anty API creates browser profiles, describes their fingerprints, attaches proxies, and starts and stops them, handing you a DevTools port you can attach Puppeteer or Playwright to. It has no campaign, budget or spend object, because those are not browser-level concepts. Campaign automation happens against the ad platforms' own APIs, on a different layer. (If the two Dolphin products are still blurry, start with Dolphin{anty} vs Dolphin{cloud}.)

Everything below was read from docs.dolphin-anty.com on 29 August 2026. Their docs move; open them the day you write your script.

---

There are two APIs, and this is where people get stuck

The single most common confusion: Dolphin{anty} exposes a remote API and a local API, and they answer different questions.

The mental model: the remote API decides what a profile is. The local API turns it on.

Try to start a profile against dolphin-anty-api.com and nothing happens. Try to create one against localhost:3001 and nothing happens. Both are documented; neither is guessable.

---

The remote API: creating a profile

Profile creation is a POST to https://dolphin-anty-api.com/browser_profiles with a Bearer token and a JSON body.

There are two helper endpoints worth knowing before you write the payload, because they save you from inventing fingerprint values that do not exist in the wild:

User agent — GET https://dolphin-anty-api.com/fingerprints/useragent?browser_type=anty&browser_version=140&platform=windows, with platform taking MacOS, Windows or Linux. Requires the Authorization: Bearer API_TOKEN header.

WebGL — GET https://dolphin-anty-api.com/fingerprints/webgl?browser_type=anty&platform=windows, same header, same platform options.

Then the creation payload. Here is the shape, taken from their published Python example:

name          platform      browserType   mainWebsite
useragent     webrtc        canvas        webgl
webglInfo     timezone      locale        cpu
memory        screen        doNotTrack    osVersion

Read that list slowly, because it tells you exactly what this product is.

useragent takes a mode of manual or otherwise and a string value. webrtc takes modes like altered with an optional IP. canvas and webgl take real. webglInfo takes a GPU vendor and renderer string — in their own example, an Intel Iris Xe reported through ANGLE on Direct3D 11 — plus WebGL2 maximums like MAX_TEXTURE_SIZE. cpu and memory take core count and gigabytes. timezone and locale take auto or a value.

Every single field describes a machine. Not a business, not a spend, not a result. The API's entire vocabulary is a description of a plausible computer, because that is the problem it was built to solve, and it solves it thoroughly.

---

The local API: launching and driving

Once a profile exists, you turn it on locally.

Authenticate first. Create a token in your personal account on their website, then:

POST http://localhost:3001/v1.0/auth/login-with-token
Content-Type: application/json

{ "token": "API_TOKEN" }

A success looks like {"success": true}. Their documentation is explicit that skipping this is what produces the 401.

Start the profile.

GET http://localhost:3001/v1.0/browser_profiles/PROFILE_ID/start?automation=1

Add &headless=1 for headless mode. The automation=1 parameter is required — without it you get a browser you cannot attach to.

The response is the interesting part.

{
  "success": true,
  "automation": {
    "port": 50568,
    "wsEndpoint": "/devtools/browser/c71c1a9d-f07c-4dd9-84a9-53a4c6df9969"
  }
}

That is a DevTools Protocol handle. From there you attach — you do not launch. Puppeteer, Playwright and Selenium all connect to the already-running browser at that port. Their documentation covers all three, with a note on the Selenium path: standard ChromeDriver can reveal automation, so they publish their own modified ChromeDriver per browser version and recommend pointing your script at that.

Stop the profile.

GET http://localhost:3001/v1.0/browser_profiles/PROFILE_ID/stop

The constraints, all documented:

• Works only while Dolphin{anty} is running.
• Requests must come from the same machine as the browser.
• Default port 3001; if busy, another is assigned — check the Health window in the app.
• Rate limit: 1,500 requests per minute.
• On the Free plan, cookie import and export via the API are unavailable, because that tier has no cloud sync.

---

The script you would actually write

Nine lines of pseudocode, and it is worth writing them out because the shape is the argument:

1.  POST /v1.0/auth/login-with-token          → authorise the local app
2.  POST dolphin-anty-api.com/browser_profiles → create profile from a template
3.  GET  /v1.0/browser_profiles/{id}/start?automation=1
4.  read port + wsEndpoint from the response
5.  puppeteer.connect({ browserWSEndpoint: ... })
6.  ...                                        ← everything you actually care about
7.  GET  /v1.0/browser_profiles/{id}/stop
8.  repeat for the next profile
9.  done

Steps 1 through 5 and 7 are Dolphin's API doing its job, cleanly. Step 6 is where every hard problem lives, and Dolphin's API has nothing to say about it — by design.

Because step 6 is where you are driving a rendered advertising interface with a browser automation library: waiting for elements, handling a modal that appeared this week, re-finding a button after a layout change, catching a partial save. Every team that has built this knows the maintenance profile. The script does not break because the API broke. It breaks because a page changed.

---

The two automation paths that are not the API

Worth knowing, because for a lot of jobs they are the better answer and they need no code at all.

The Script Builder. Dolphin{anty} ships a visual scenario builder for browser automation across profiles, documented in its own help-centre section and advertised on the homepage as available for Windows, Linux and macOS. Their marketing framing is farming, data collection "and anything else your heart desires". One of the reviews they publish makes the practical case bluntly: a user managing 500+ accounts says the scenario builder cut registration and account-management time roughly tenfold with one pair of hands. If your automation is a repeated sequence of clicks inside profiles, this is cheaper than writing and maintaining Puppeteer.

The profile synchronizer. Marked beta on their homepage: run several profiles through the synchronizer and every action from the master profile is repeated in the others. It is the manual-but-parallel option — you drive one browser and the rest follow.

The reason to mention both in an API article is honesty about scope. A lot of what people ask the API for is a scenario, not a script. Reach for the API when you need profiles created programmatically from a data source, launched in a pipeline, or driven by logic that a visual builder cannot express. Otherwise you are maintaining code to do something the product already does.

---

What the API knows, in one table

Neither column is missing anything. They are two inventories of two different worlds, and the empty cells are the reason both tools exist.

---

The boundary, stated plainly

The Dolphin{anty} API can create a profile, clone it, describe its fingerprint, attach a proxy, start it, stop it, hand you a DevTools port, and manage cookies on paid tiers.

It does not know what a campaign is. It does not know what a budget is. It does not know what you spent yesterday, and it has no field in which such a thing could be stored.

That is the cleanest and most honest boundary in this market, and it is worth saying without any edge on it: a browser API automates identity. It was never trying to automate media buying. Anyone who tells you their anti-detect browser "automates your ads" is describing browser automation against a UI, which is a real technique with a real maintenance cost, not an ad API.

---

What the other side of the boundary looks like

Here is our own product, described so you can weigh it against the above.

Wevion works against the ad platforms' own marketing APIs with OAuth — Meta, Google, TikTok, Taboola, Snapchat and Outbrain. Campaigns, ad sets, ads, budgets and results are objects with IDs, not elements on a page. Nothing to select, nothing to wait for, nothing that breaks when a layout ships.

And Wevion has its own programmable surface, described with the qualifications that keep the sentence honest:

The catalogue. Our MCP server exposes 769 operations, 422 of which write, on a single API key — five ad platforms plus trackers, commerce and creative. There is also a published CLI.

Four things you should know before that number means anything to you:

1. It is a Pro-plan feature and up. API access is off on the Free and Starter tiers — max_api_keys is zero there.
2. No customer runs it today. Nine keys exist in production, all internal or test, with 58 requests across the whole lifetime of the thing. It is a real surface with real coverage and effectively no adoption. That is the truth, and quoting the 769 without this line would be selling a number rather than a product.
3. It is a catalogue computed from our public OpenAPI specification, not an authenticated tools/list we ran and counted.
4. There is no confirmation gate inside the MCP surface itself. Route-level guards apply, but the approval step that exists elsewhere in the product is not part of this path. If you wire an agent to it, you are wiring an agent to writes. On Meta specifically, budget changes are not in the MCP catalogue.

We are also not claiming to be alone here. Several vendors publish read/write MCP surfaces, some of them free, and at least one ships both MCP and a CLI from a low monthly price. The honest framing is breadth under one key, not exclusivity.

---

What actually runs the campaigns

The programmable surface is not where most of the value sits, and it would be strange to pretend otherwise given the adoption number above. This is what the product does on its own:

Six platforms, connected the same way — Meta, Google, TikTok, Taboola, Snapchat, Outbrain. Connect, launch, sync and measure across all six.

With the smaller numbers said first. Budget moves driven by the rules engine run on five (Outbrain has no branch). Rules comparing one platform against another run on four: Meta, Google, TikTok, Taboola. Pause and activate at ad-set and ad level: three — Meta, TikTok, Snapchat. Launch rollback and relaunch: Meta only.

Rules on a 15-minute cadence, with 33 condition metrics — including profit, profit_margin, true_roas and break_even_roas, so a rule can act on contribution margin instead of on the platform's reported return.

An asymmetric brake. Stopping autonomy halts activations, budget increases and relaunches, and lets pause and budget decrease keep running.

Budget Pools. One daily budget across campaigns from several platforms, redistributed every eight hours, with a simulation before and an allocation log after.

Ten tracker adapters — BeMob, Binom, ClickFlare, Everflow, ExoClick, Keitaro, RedTrack, SearchFeed, TrafficManager, Voluum.

Roles and a record. Organization → team → workspace → access groups, with an audit log you can query in plain language.

And what we do not have, in the same voice:

• No creative uniqueization at launch. It is on Dolphin{cloud}'s feature list. It is not in our product.
• Launch rollback is Meta-only — the other five have no undo for a bulk launch.
• No identity layer at all. No profiles, no fingerprints, no proxies, and no intention of building them. If your automation problem is "keep forty logins apart on one machine", the Dolphin{anty} API is the right tool and we are not a substitute for it.
• Seats on the entry plan are our sharpest edge — on Starter, additional seats cannot be purchased.

---

The summary a developer would want

• Two APIs. dolphin-anty-api.com with a Bearer token creates and describes; localhost:3001 starts, stops and hands you a DevTools port.
• Authenticate the local one first via POST /v1.0/auth/login-with-token, or expect a 401.
• automation=1 is mandatory on start; headless=1 is optional.
• Attach, do not launch. Take port and wsEndpoint and connect Puppeteer, Playwright or Selenium — with their modified ChromeDriver on the Selenium path.
• 1,500 requests per minute, same machine, app running. Free tier has no cookie import/export.
• The profile payload is a machine description. No campaign, no budget, no spend — and that is the boundary of the layer, not a gap in the product.

---

Next steps

• Not sure which Dolphin product you have: Dolphin{anty} vs Dolphin{cloud}.
• Working with the Cloud bridge: what the Dolphin{cloud} extension does.
• Want campaign objects instead of CSS selectors: try Wevion on the free plan. It authorises via OAuth against the ad accounts you already have — nothing to migrate, and your browser stack stays exactly as it is.