API09.07.20266 min

Profiles from code and AI tools

The remote control, CLI, HTTP API and MCP use one service layer: everything that the button can do, so can the request. Available on any plan, including free.

01One layer, four inputs

NimbusX does not maintain separate manual and automation paths. The dashboard, command line, local HTTP API and MCP server call the same service layer, so every supported action follows one contract.

02Local API

API listens only 127.0.0.1 and requires the token from the app. The versioned endpoint is stable, while the idempotency key prevents a retry from creating a second profile:

$ curl -X POST http://127.0.0.1:8710/api/v1/profiles \ -H "X-Antidetect-Token: $TOKEN" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: market-01" \ -d '{"name":"market-01"}'

03Automation through the API

The raw CDP port stays private because it would give any local process full control of the browser. Navigation, JavaScript evaluation, page text and screenshots are available through the authenticated API:

# Python from app.client import Client api = Client() api.launch("market-01") api.goto("market-01", "https://iphey.com") title = api.evaluate("market-01", "() => document.title") api.screenshot("market-01", "check.png") api.stop("market-01")

04MCP for AI tools

MCP uses stdio and talks to the same local service. The model sees only the documented tools for profiles, proxies, devices, licensing and test history. Launching or deleting a profile remains an explicit user-directed action.

{ // packaged app configuration "mcpServers": { "nimbusx": { "command": "C:\\Program Files\\NimbusX\\NimbusX.exe", "args": ["mcp"] }} }

05Automation on every plan

API and MCP are available on every plan, including the free plan with five profiles. Plans limit profile count, not how profiles are controlled.