Undetectable.io Automation API With a US Mobile Line

Undetectable.io exposes a local HTTP API when the desktop app is running. Through it a script can create profiles, set their proxy, start and stop them, and get a remote-debugging address to attach Playwright or Puppeteer. Combined with a line from Mobile Proxies US, this gives a controlled browser identity on a US carrier address that your code owns end to end. This page shows the sequence and the proxy fields, and where the line's rotation fits between runs.

Why a profile browser plus a carrier line

A headless browser with a proxy gets the address right and the fingerprint wrong: the automation flags, the canvas and font set, the missing plugins all read as a bot. A profile browser gets the fingerprint right and, with a datacenter proxy, the address wrong. Undetectable.io on a mobile line gets both right: a consistent desktop or mobile fingerprint and an exit on AT&T, T-Mobile or Verizon shared with real subscribers.

Keep the pairing stable. One profile, one line, for the life of the account you run in that profile. The profile's fingerprint and the line's carrier and metro together are the identity; changing either half mid-way is what trips risk systems, not the proxy itself.

The local API and where it listens

With the app open, Undetectable.io's own API listens on localhost on a port shown in the app's settings. Requests are plain JSON over HTTP. The main calls are: list profiles, create a profile, update a profile, start a profile, stop a profile. Start returns a websocket debugger URL; that is what Playwright's connect_over_cdp or Puppeteer's connect takes.

The app must be running for the API to answer. For unattended runs on a server, that means a desktop session (a VM with a display, or a virtual framebuffer) that launches the app at boot. Plan for that before writing the script; it is the one operational requirement that surprises people.

Creating a profile with the line as its proxy

A profile's proxy setting holds a type, host, port, login and password. Use http as the type with the HTTP endpoint of your line; SOCKS5 works too but HTTP has fewer surprises with WebRTC handling inside the app. Set the profile's timezone and locale to match the line's metro and language, or let the app derive them from the proxy's IP, which it can do at start.

Fetch the proxy values from the Mobile Proxies US API rather than copying them by hand. A short function that reads GET /proxies/my, picks a line by licence uuid and returns the proxy values keeps the two systems in sync and makes it easy to rebuild a profile after a move, when the host and ports can change.

import os, requests
BASE = "https://cp.mobileproxiesus.com/backend/api_v1"
H = {"x-api-key": os.environ["MPUS_API_KEY"]}
UNDT = "http://127.0.0.1:25325"   # Undetectable.io's own local API; see the app settings and its docs
line = next(l for l in requests.get(f"{BASE}/proxies/my", headers=H, timeout=15).json()["proxyList"]
            if l["uuid"] == UUID)
login, password = line["authentication_user"].split(":", 1)
# body shape belongs to Undetectable.io; check its API docs for your version
profile = {
  "name": f"line-{line['uuid'][:8]}",
  "os": "win",
  "proxy": {"type": "http", "host": line["host"], "port": line["http_port"],
            "login": login, "password": password},
  "timezone": "auto", "geolocation": "auto", "language": "auto"
}
pid = requests.post(f"{UNDT}/profile/create", json=profile).json()["data"]["profile_id"]

Starting the profile and attaching Playwright

Start returns a debugger address. Connect Playwright over CDP to that address, take the default context (it holds the profile's cookies), and automate as usual. Do not launch a new browser from Playwright; you want the app's browser with its fingerprint, not Playwright's bundled Chromium.

Before doing anything else in the session, load an IP echo page and assert the address is the line's current exit. That one check catches a profile that silently fell back to direct connection because the proxy fields were wrong.

from playwright.sync_api import sync_playwright
start = requests.get(f"{UNDT}/profile/start/{pid}").json()["data"]
ws = start["websocket_link"]
with sync_playwright() as p:
    browser = p.chromium.connect_over_cdp(ws)
    ctx = browser.contexts[0]
    page = ctx.new_page()
    page.goto("https://api.ipify.org")
    expected = requests.get(f"{BASE}/proxy/status", params={"license": UUID}, timeout=15).json()["ip"]
    assert page.inner_text("body").strip() == expected
    # ... your automation ...
requests.get(f"{UNDT}/profile/stop/{pid}")

Rotation between runs, never during

Rotate the line only while the profile is stopped. A rotation while the browser has sockets open resets them, and a session that changes address between two page loads looks exactly like a stolen cookie. The clean sequence is: stop profile, rotate line, wait for the new exit IP, start profile, verify, run.

How often to rotate depends on the account. For a long-lived account, rarely or never: a real phone keeps its address for hours. For a sequence of independent checks (several test cases, several public page reads), once per case is fine. Put the decision in your script as a parameter, not a habit.

def status_ip():
    return requests.get(f"{BASE}/proxy/status", params={"license": UUID}, timeout=15).json()["ip"]
def fresh_run(pid, line):
    requests.get(f"{UNDT}/profile/stop/{pid}")
    before = status_ip()
    requests.get(line["rotation_link"], timeout=30).raise_for_status()
    wait_until(lambda: status_ip() not in (None, before), timeout=90)
    return requests.get(f"{UNDT}/profile/start/{pid}").json()["data"]["websocket_link"]

Operational notes

Store the mapping profile id to licence uuid in your own database. The Undetectable.io profile name is a convenient place to repeat the uuid, but the database is the source of truth. When a plan ends and the line returns to stock, the profile should be retired with it or re-pointed at a new line deliberately.

Logs: record licence uuid, exit IP and profile id on every run. When something fails days later, the triple is what lets you tell a proxy problem (address changed, line lapsed) from a fingerprint problem (profile altered) from a site-side change. Undetectable.io is our first recommendation for this workflow; GoLogin is the second and has an equivalent API covered in a separate page.

Frequently asked