Skip to content
PowerOps

Automation

Drive the same profiles from your own scripts

PowerOps runs an HTTP API on http://127.0.0.1:50326. Everything the application does to a profile can be done from your own tooling, on your own machine, without a cloud service in the path.

PowerOps · API
Search

Listener online

Originhttp://127.0.0.1:50326
Keypk_live_••••••••••••7f2a

Endpoint groups

StatusBrowserProfilesProxiesGroupsExtensions

# open a profile and attach to it

POST /browser/start x-api-key: pk_live_••••7f2a

{ "profileId": "pf_a41f", "group": "Paid social" }

→ 200 { "ws": "ws://127.0.0.1:50327/devtools/browser/…" }

The listener binds loopback. Every route but the status check needs the key.

Endpoint groups

What the API covers

Six groups, covering the operations the application itself performs. Nothing here is a wrapper around a remote service.

  • Status

    Whether the API is up, which version it is, and how long it has been running. The one route that does not require a key.

  • Browser

    Start a profile's browser, stop it, and ask which are running. Starting one returns the debugging endpoint it published, so an automation library can attach.

  • Profiles

    Create, update, query and delete profiles, including their identity, network and browser build.

  • Proxies

    Add endpoints, verify them, and assign them to profiles.

  • Groups

    Create and query groups, and move profiles between them.

  • Extensions

    List imported packages and assign them to profiles.

A first request

One header, one URL

The status route is the only one that does not need a key, which makes it the right thing to point a health check at. Everything else takes the same bearer header.

# is it up?
curl http://127.0.0.1:50326/status

# everything else takes the key
curl -H "Authorization: Bearer YOUR_API_KEY" \
  http://127.0.0.1:50326/api/v1/browser/start?user_id=YOUR_PROFILE

Starting a browser hands back the debugging endpoint that browser published, so an existing automation library attaches to a real PowerOps profile rather than to a browser you had to launch yourself.

Security

Local means local

  • Binds 127.0.0.1. No setting makes it listen on another interface.
  • A bearer key is required on every route except the status check, and compared in constant time.
  • The Host header is checked, and no CORS headers are sent. A web page cannot reach it through your browser.
  • Profile passwords, 2FA secrets and proxy passwords are never returned by a query endpoint.
  • Cookies come only from their own authenticated endpoint, never inside a profile record.
  • Request bodies are capped, and the API is rate limited.

Getting a script running

  1. 1

    Turn the key on

    Open the API screen in PowerOps. It shows whether the listener is online and which port it is bound to. The key sits there too, masked until you ask for it.

  2. 2

    Point your script at loopback

    Send requests to http://127.0.0.1:50326 with the bearer header. The status route needs no key, so it is the right thing to wait on at startup.

  3. 3

    Attach to the browser it launches

    Start a profile through the API and use the debugging endpoint it returns, so your automation drives a real PowerOps profile with its own identity and route.

What it is, and is not

  • Not a cloud API

    There is no hosted endpoint for this. It runs inside the application, on your machine, and stops when the application does.

  • Honest failures

    An operation PowerOps does not implement returns 501 with an explanation, never a fabricated success.

  • Documentation that cannot drift

    The reference is generated from the specification the application itself serves.

  • A tester where it is safe

    Interactive docs are served from the same origin as the API, on your machine, where your key never crosses a network.

  • Port you control

    The port is visible and changeable from the API screen.

  • Regenerable key

    Rotate the key from the same screen; the old one stops working immediately.

The Local API, answered

Is the API reachable from the internet?

No. It binds 127.0.0.1, and there is no setting that makes it listen on another interface. It also checks the Host header and sends no CORS headers, so a web page cannot use your own browser as a route into your machine.

Do I need a key?

Yes, on every route except the status check. The key is sent as a bearer token and compared in constant time, and PowerOps never puts it in a URL. You can see it, copy it and regenerate it from the API screen in the application.

Can I use my existing automation scripts?

The route shapes and the response envelope follow the local API surface that multi-profile browsers converged on, so scripts written against that shape work here. They are implemented against PowerOps' own services rather than proxied to anything.

What happens for an operation PowerOps does not implement?

It returns 501 with a plain explanation. It does not return a fabricated success, which is the failure mode that costs an afternoon of debugging the wrong thing.

Where is the reference documentation?

While PowerOps is running it serves interactive documentation at http://127.0.0.1:50326/docs on your own machine, where you can send real requests with your own key. That is deliberately the only place with a request tester: a website that sends requests to your 127.0.0.1 is the shape of an attack, and the API is built to refuse it.

Script your browser operations

The listener ships inside the desktop application, and the paid plans open it. The trial runs it for 30 days without a card.