Capture the screen after an action
Addcapture 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:
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 still200, 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
waitsteps where the screen needs time to settle, for example after a tap that opens a new screen. Allwaitsteps in one chain add up to at most 120 seconds. captureat the top level isnone(default),eachorfinal. A step’s owncaptureoverrides it, for example{ "verb": "tap", "params": { "index": 4 }, "capture": true }.
Results
The response hasok 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-levelokistrueonly if every step succeeded. Checksteps[n].okto 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 (
402or503on a Lusor Phone). The response is that error alone, without per-step results, and the steps before it have already run on the phone.
402 or 503 stops it before that step reaches the phone. See Billing.
