Remote API

#The Local API, from anywhere

The Remote API is the Local API's own routes — the same paths, the same bodies, the same answers — reached from outside this computer instead of only 127.0.0.1. Nothing new is exposed: a request still ends up at the exact same route handler the Local API uses, running on your own desktop app. Only the wire is different — a private relay instead of a port opened on your machine, which there never is one of, even while the Remote API is on.

#How it reaches you

Your desktop app only ever makes an outbound connection — the same one it already uses to pair a phone over Wi-Fi. While the Remote API is on and you're signed in, it holds that connection open and answers requests placed through mobyx.app on it. A caller never connects to your computer directly, and your computer never listens for the internet: if the app is closed, signed out, or the Remote API is off, a call simply times out, the same as any offline server would.

#Turn it on

Account → API → Turn on, after making a key. Unlike the Local API's key, this one is made on the account page, not inside the app — it has to be known to the server that relays your calls, so it can tell whose they are before anything is forwarded to your desktop. The desktop app itself needs nothing set up: once it's signed in and the Remote API is on for your account, it joins the relay automatically.

#Making a call

Swap the Local API's base URL and key for these, and most existing code just works:

curl -H "X-API-Key: mrk_..." https://mobyx.app/api/remote/v1/phones

curl -X POST -H "X-API-Key: mrk_..." -H "Content-Type: application/json" \
  -d '{"engine":"chrome","start":true}' https://mobyx.app/api/remote/v1/browsers

Same header (X-API-Key, or Authorization: Bearer), same {"ok": true, "data": ...} / {"ok": false, "error": {...}} shape, same status codes as the Local API — with one more: 504 timeout here most often means the desktop app isn't reachable right now (closed, signed out, or the Remote API turned off), not that a call ran long.

#Live events

GET /api/remote/events, with the same key, opens a Server-Sent Events stream: workflow run progress and devices going on or offline, pushed the moment they happen instead of polled for. A standard EventSource reconnects on its own — this is the one difference worth knowing, since the connection is recycled periodically on purpose rather than held open forever.

const events = new EventSource("https://mobyx.app/api/remote/events?key=mrk_...");
events.addEventListener("mobyx_event", (e) => console.log(JSON.parse(e.data)));
events.addEventListener("presence", (e) => console.log(JSON.parse(e.data).online));

#Privacy, and what it can see

• The key is stored as a one-way hash, the same way a password is — mobyx itself cannot read it back, only tell whether a key presented to it is a match.
• It is shown to you once, right after it's made; afterwards the account page shows only its last 4 characters.
• A request is relayed, never logged or kept — the body of a call (a URL to open, text typed into a phone) passes through only for as long as it takes to answer.
• It needs the same 3 Months or Yearly plan the Local API does, and closes the moment you sign out, same as the Local API.
• Revoking a key ends access at once; turning the Remote API back on afterwards needs a new one.
• An admin can see that an account has a key, its last 4 characters, and when it was last used — never the key itself, and never what it was used to do.

#What it answers

Exactly the Local API's own routes and error codes — see that page's reference, and the full list at /docs/api-reference. Binary answers (a screenshot) aren't carried over the relay today; those still need the Local API.