Skip to main content
Both features work on every direct-control action and save you round trips.

Capture the screen after an action

Add capture to any action to get the screen as it is right after the action, so you skip a separate /state call:
capture: true returns the element tree with default options. Pass an object to change them:
The response then carries a capture object:
screenshot_url takes a new screenshot each time you fetch it. It shows the screen at fetch time, not the moment after the action, so fetch it straight away, before the next action. It needs the same API key, and on a Lusor Phone it is metered like any other GET …/screenshot.

When the capture fails

The action has already run when the capture is taken. If the action succeeds but the capture fails, the response is still 200, with:
Do not retry the action, because it ran. Read the screen with GET …/state instead. On your own iPhone, a capture that asks for the element tree always fails this way. Inside a chain, a capture failure aborts the chain instead (see below).

Chains

POST …/chain runs 1 to 20 actions in order in one request.

Steps

Each step is { "verb": …, "params": { … } }, with an optional capture next to params. The params are the same as the body of the matching action endpoint.
  • Steps run back to back, with no pause between them. Add wait steps where the screen needs time to settle, for example after a tap that opens a new screen. All wait steps in one chain add up to at most 120 seconds.
  • capture at the top level is none (default), each or final. A step’s own capture overrides it, for example { "verb": "tap", "params": { "index": 4 }, "capture": true }.

Results

The response has ok and one entry in steps per step, in order. Each entry has the step’s verb, ok, exit_code and status, plus resolved (for a tap), cleared and capture when they apply.

When a step fails

There are two kinds of failure, and they behave differently.
  • A step completes with ok: false. The chain keeps going. The top-level ok is true only if every step succeeded. Check steps[n].ok to find the failure.
  • A step errors. The chain stops. This happens when the phone cannot be reached, when a step’s capture fails, or when billing refuses a later step (402 or 503 on a Lusor Phone). The response is that error alone, without per-step results, and the steps before it have already run on the phone.
After an error, you cannot tell from the response how far the chain got. Read the screen before you retry a chain.
On a Lusor Phone, a chain is metered before each step, so a 402 or 503 stops it before that step reaches the phone. See Billing.