Driving iOS No-Jailbreak Scripts from Python: Open API Steps and Parameters

The alert is outside. The phone action goes through the API

Last month, at a customer site, the support system popped an “order exception” in the middle of the night. The order had to be submitted again inside the phone app. The system knew something was wrong. The control center did not. The person on duty was already asleep.

Can the support system tap by itself? Yes.

What the open API does is plain. It turns a phone action into an HTTP request. An order system that can send a request can drive the phone. An alert system and a business back end can do the same.

The API should stay off by default. It is worth connecting when the trigger lives outside the control center. For example, the order system decides when to resubmit, or the back end decides which device runs. A cadence you want to control yourself also fits the API, and the result can be written back into your own database.

A fixed script at a fixed time is already covered by the scheduler in the EasyClick control center. Wrapping another API around it only adds a place you have to maintain.

If the control center can decide when to act and what to do, leave the API unconnected. Connect it when the decision comes from another system.

There is no SDK here. Ordinary HTTP is enough.

The address is the control-center computer plus port 8019. A call on the same machine is http://127.0.0.1:8019. A call from another machine uses the LAN IP of the control-center computer.

The method is HTTP POST. Set Content-Type to application/json and put the parameters in the body. The response is JSON too. code 0 means success. Any other value means failure, and the reason is in msg.

Wrap that check first:

import requests

BASE = "http://127.0.0.1:8019"

def openapi_post(path, body=None):
    r = requests.post(f"{BASE}{path}", json=body or {}, timeout=30)
    r.raise_for_status()
    data = r.json()
    if data.get("code") != 0:
        raise RuntimeError(data.get("msg") or data)
    return data

Later calls all go through this function. Python depends only on requests. Node.js 18 and later already includes fetch.

Get deviceId right, or the tap lands in the wrong place

Every device API recognizes deviceId. Query the device list first. Leave hand-typed values from memory out of it.

devices = openapi_post("/openapi/deviceList", {"deviceId": "", "groupId": ""})
print(devices)

An empty string for deviceId means no device filter. An empty groupId means no group filter. Fill groupId in when you want one group only.

The API uses the deviceId returned in the list. The alias is only shown on screen. Calling with the alias wastes a round trip.

USB HID cannot start with a tap either. The order is fixed:

DEVICE_ID = "90e2f3834c0977205e441aa664916a9bdde81e8d"   # take it from the device list

# 1) open the session
openapi_post("/openapi/usbhidSessionStart", {"deviceId": DEVICE_ID, "gate": True})

# 2) set the screen resolution (coordinate conversion depends on it)
openapi_post("/openapi/usbhidSetScreenSize", {"deviceId": DEVICE_ID, "w": 1170, "h": 2532})

# 3) only then tap
openapi_post("/openapi/usbhidClickPoint", {"deviceId": DEVICE_ID, "x": 200, "y": 400})

Open the session first. gate is whether to try enhanced compatibility mode, and it is usually true. Older systems ignore it on their own. If the session already exists, it is reused. You do not reopen it every time.

Then set the screen size. This step is the one most often skipped, and skipping it sends the tap off target. HID sends absolute pixel coordinates. Without w and h, it has no conversion. The 1170 × 2532 here has to match the resolution in the mirror or the screenshot.

The tap comes last. The sample coordinates are x=200 and y=400. Different device resolutions are calculated separately. One hard-coded coordinate set can land beside the target on the next phone.

With the session open and the size set correctly, the next few hundred taps call only the third step. You do not set it again. The Node.js shape is the same. The request becomes fetch:

const BASE = "http://127.0.0.1:8019";

async function openapiPost(path, body = {}) {
  const res = await fetch(`${BASE}${path}`, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(body),
  });
  const data = await res.json();
  if (data.code !== 0) {
    throw new Error(data.msg || JSON.stringify(data));
  }
  return data;
}

The API splits into eleven groups. This table is faster than paging through the docs:

Module	What it covers
Control-center API	Device list, script start and stop, and similar
Automation, actions	Tap, swipe, input, open and close apps
Automation, screenshots	Screenshots, image streams
Automation, start and stop	Start and release automation, tunnel, battery
Automation, Photos	Upload images and video, clear Photos
Automation, file operations	Push and pull device files
Automation, IME input method	Custom input method, clipboard forwarding
Automation, Bluetooth BLE	HID actions for the Bluetooth board
Automation, USB HID	No extra hardware. The data cable controls the phone directly
Assistant	Assistant clipboard, Photos, port forwarding
Shortcuts assistant	Used together with the Shortcuts assistant program

The actions group is the one used most. Tap, double-tap, long-press, swipe, multi-touch, and text input are all in it. A simulated keyboard, opening or closing an app, and installing or uninstalling an app belong there too. Home, restart, lock and unlock, screen orientation, coordinate correction, and node capture can be called as well.

USB HID needs its own note. This group of APIs is available from EC iOS USB 10.7.0 (2026-09-08). It needs no Bluetooth board and no OTG board. iOS 17 or later is recommended for the phone. One data cable can simulate taps and input. It is mutually exclusive with Start Automation in the control center and with startEnv in a script. Keep them off the same device. When you need a screenshot, use screenshot without automation. On the Start Automation path, iOS 15 and later can use offline main program v7.2.0 and later as the automation service. The official download page has a pre-signed IPA, and i4Tools can install it for a test. If you sign it yourself, an individual developer account is 688 yuan a year, can bind 100 devices, and supports iOS 12 and later. The fee is signing only. TrollStore supports iOS 15 through 16.6.1, and a restart drops the signature. The offline build supports iOS 15 and later only. From 7.0.0, single app installs only the main program: choose Single app in settings, then turn automation on. Dual app also signs the proxy IPA, and if it drops, self-activation can bring it back up. From EC iOS 10.6.0 (2026-09-02), the AI agent is upgraded to iEasyRun, at https://ieasyrun.com .

The API only triggers. The full flow stays in the script

The control-center API first answers which device you are managing. Call the device list and get a batch of deviceId values, then start the compiled script on each one. When order ownership lives in an external system, that split saves work.

With more devices, group them in the control center first. The API is still called per deviceId, one device at a time, and your code owns the loop. The group gives that loop a clear range. Pulling every device on every call gets messy fast.

If you want an AI assistant to call the phone directly, register the API as an MCP tool. On a direct call, you write the API and the parameters. Once it is MCP, the AI assistant picks the tool and fills the parameters. MCP fits better when the next step has to be judged on the spot. A fixed action stays a direct call. That is less work.

Split errors apart. Control center closed, or the port unreachable, is a network or service problem, and a retry can help. Device offline, license expired, or coordinates out of range usually gain nothing from a retry. Read msg first. Leave a blind resend for later.

Leave timeouts un-unified too. The official sample is 30 seconds. Ordinary action APIs often return in a few hundred milliseconds. Screenshots and uploads move large files and need more time. How many seconds to allow on site is measured per API group.

Coordinates wear people down the most. When models are mixed, convert by resolution. If you can capture a node, take the element coordinates and then tap. Hard-coded values look fine on the test phone and drift on the next device.

Logs should keep at least five things: device ID, API name, request parameters, code and msg, and a timestamp. Miss one and matching the scene can cost an extra half hour.

Leave the API out of rewriting a whole phone flow. Put the flow in the device script. The API only triggers it and fetches the result. Fewer requests, fewer network round trips. When something breaks, the area you have to search is much smaller.

What you need	Recommended path	Why
Run a fixed flow on a schedule	The scheduler in the EasyClick control center	An extra API layer is unnecessary. The control center can decide when to act on its own
An external system decides when to trigger	Call the EasyClick open API directly	Port 8019, HTTP plus JSON, connected straight to the system you already have
An AI should decide the next step	Register EasyClick as an MCP tool	The AI picks the tool and fills the parameters. You skip writing the scheduling logic
Precise control of UI elements, and a full flow running on the device	EasyClick proxy mode with a script, and the API only as the trigger	The flow stays on the device, network round trips stay few, and the places that can break stay few

Fixed flows use the scheduler. External triggers use the API. Decisions go to MCP. The concrete actions on the phone still belong to the script. That cross-border team ended up letting the alert system do three things: look up the matching device, start the “resubmit order” script, and write the result back to the ticket table. If the cloud-control side needs the same scheduling, the open API notes match cloud control 3.11.0 and later and EC client 9.4.0 and later. The demo site account is test123 / test123.

To see how the script itself is written, read how to write an iOS no-jailbreak script. For the USB HID idea and the full API, see the USB HID automation script tutorial. For connecting the API to an AI system, read cloud control open API and MCP integration.

---

About EasyClick: A mobile automation script development platform covering three phone ecosystems: Android without root, iOS without jailbreak, and HarmonyOS. It also offers Apple script writing, Apple cluster control, Android cluster control, remote cloud control, and AI phone cluster control. → Explore all products