iRemotech Device API — changelog

Changes to the /v1 API that are already in effect, newest first. Upcoming behaviour changes are listed on the announced changes page until they go live — if the API is integrated into an automated workflow, check that page at least once a week.

2026-10-02 — launch Instagram automations

• New POST /v1/devices/{id}/automations (new scope automations): launch a warm_up, account_status or list_accounts automation on one of your phones. Answers 202 with the queued job. See README §4b.
• New GET /v1/automations/{job_id} and GET /v1/devices/{id}/automations (scope read): follow a job (queued → dispatched → completed / failed / needs_review / expired) and read its result. account_status returns six account_state flags, each green, warning or unknown; any counter in result can be null. Reads are limited to 10 per second per account (burst 20).
• While an automation runs, leave the phone alone: any request that reaches the phone (an action, a screenshot, the device detail, a live stream or live control) may interrupt the job, which is tried again 5 to 7 minutes later and abandoned after three interruptions. See README §4b.
• An accepted launch counts as one action toward the daily actions budget. A warm_up uses your agency's automation tokens: it is launched only when the balance covers the session length plus 120 seconds of overhead, and is otherwise refused with 402 insufficient_tokens; a warm-up that does not complete is not charged. Launch limits: 10 per minute per device (burst 3) and 2 per second per account (burst 10), plus the per-automation limits in README §4b.
• Existing keys do not have the automations scope, and the scopes of an existing key cannot be changed: create a new key in the dashboard to launch automations (new keys include every scope).
• New error codes: insufficient_tokens (402), account_not_found (404), job_not_found (404), automation_pending (409; a job started from the dashboard for the same account or phone also blocks). The new endpoints also return upstream_unavailable (503); a launch is not idempotent — retry with a growing delay, and a 409 automation_pending on the retry most likely means the first launch was queued. See README §4b.

2026-09-30 — edit devices: name, notes, labels

• New PATCH /v1/devices/{id} (new scope manage): rename a device, set or clear its notes, and replace its labels — send only the fields you want to change. Labels are addressed by name; a name your account does not have yet is created. Not counted toward the daily budgets; limited to 10 edits per minute per device (burst 5) and 5 per second per account (burst 20). See README §3b.
• Existing keys do not have the manage scope, and the scopes of an existing key cannot be changed: create a new key in the dashboard to use the endpoint (new keys include every scope).
• GET /v1/devices and GET /v1/devices/{id} now return labels: [{name, color}] in display order ([] when none). Additive.
• notes and custom_name are now returned as null rather than an empty string when empty.
• New error codes: label_limit_reached (422), rename_unavailable (503), upstream_unavailable (503).

2026-09-29 — device detail shows the snapshot size

• GET /v1/devices/{id} now returns snapshot: {width, height} next to screen: the pixel size of screenshots and stream frames, i.e. the coordinate space of every action. screen (logical points) is informational only. Additive.

2026-09-25 — scroll

• scroll (REST and live control) now moves the phone's pointer to (x, y) before the wheel notches; a scroll with the pointer idle used to have no visible effect.
• dy is clamped to ±20 notches per message (values beyond are applied as ±20). Send ±1 per wheel event for a natural feel.

2026-09-24 — live control channel

• New WS /v1/devices/{id}/control?token= (scope control): stream raw pointer, scroll, key and text messages and the phone follows in real time. One gesture counts as one action; the open channel counts as device-in-use like a stream. See README §5b. Additive — nothing changes for existing clients.
• A mouse press sent while the phone's pointer is still travelling to the point is applied once the pointer has arrived and settled, and the release no earlier than a short minimum hold, so a tap after a jump across the screen still registers. Taps with the pointer already at the target are unaffected. See README §5b.

2026-09-22 — live stream keepalive on a still screen

• WS /v1/devices/{id}/stream re-sends the last frame after a few seconds without a screen change, so an idle phone no longer leaves the socket silent. It is a normal binary JPEG, identical to the previous one — nothing changes for clients that decode every message as a frame. Do not reconnect when frames stop arriving; the screen is simply unchanged.

2026-09-15 — device custom_name and notes

• GET /v1/devices and GET /v1/devices/{id} return custom_name and notes (null until set in the dashboard).

2026-09-10 — path action

• POST /v1/devices/{id}/actions accepts type: "path" — a single-stroke gesture through 2..200 points.

2026-09-08 — double_tap action

• POST /v1/devices/{id}/actions accepts type: "double_tap" with gap_ms.