Try now →

Controlling the Browser

Show, hide, navigate, and screenshot the Wonda Automation Browser on your machine from the API.

What the WAB is

The Wonda Automation Browser is a real, hardened Chrome window on your machine holding a persona's logged-in session. It launches on demand and runs offscreen by default. These endpoints let an API client surface it, point it somewhere, and see what it is showing - the same controls the MCP wab_* tools expose.

These act on your machine and need the Wonda desktop app running. When it is offline they return a clear error; the cloud twin has its own login flow.

Commands

POST /twin/sessions/{persona}/wab/{command}
CommandEffect
showBring the window on screen so a person can watch
hideReturn it to running offscreen
openNavigate it to a URL (requires target)
screenshotCapture what it is currently displaying
checkReport whether the session is still signed in (requires platform)

open takes a target:

curl -X POST \
  https://api.wondercat.ai/api/v1/twin/sessions/natty/wab/open \
  -H "Authorization: Bearer $WONDA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"target": "https://www.linkedin.com/feed/"}'

open requires a non-empty target; a body with only platform is rejected with 400. platform is what the check command takes. The command set is fixed and the argv is built server-side, then re-validated on the relay - a client cannot smuggle an arbitrary command through.

Status across every persona

Status is account-level, so it has its own endpoint rather than a per-persona one:

curl -X POST https://api.wondercat.ai/api/v1/twin/wab/status \
  -H "Authorization: Bearer $WONDA_API_KEY"

It lists each persona and whether its browser is running.

Signing a persona in

Sessions lapse. Recovering one is a human step by design: open the platform's login page in a visible window and let the person sign in themselves, including 2FA.

# 1. surface the window
curl -X POST https://api.wondercat.ai/api/v1/twin/sessions/natty/wab/show \
  -H "Authorization: Bearer $WONDA_API_KEY"

# 2. navigate it to the platform's login page
curl -X POST https://api.wondercat.ai/api/v1/twin/sessions/natty/wab/open \
  -H "Authorization: Bearer $WONDA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"target": "https://x.com/login"}'

# 3. after the person signs in, confirm (platform is required here)
curl -X POST https://api.wondercat.ai/api/v1/twin/sessions/natty/wab/check \
  -H "Authorization: Bearer $WONDA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform": "x"}'

This flow never handles credentials: the person types them into the browser themselves, and no WAB endpoint accepts a password.

A separate credential API does exist - POST /credentials takes a password, PATCH /credentials/{id} can update it, and reads can return it decrypted - so do not tell users that platform passwords never cross the API boundary. Prefer this human-in-the-loop flow where you can: it keeps the secret off your integration entirely.

Related