Skip to main content
Most of this site describes what the control plane does. This page describes what it does not, because finding that out three days into an integration is expensive and finding it out here is free. Nothing below is a soft no with a roadmap behind it unless it says so.

​
It is not a network or identity layer

This surface drives a device. It does not shape how that device appears to the software running on it.
  • No proxy or egress control. You cannot select an exit address, a region, or a network route through any tool on this surface. There is no proxy configuration, and adding one is not planned here.
  • No device identity control. There is nothing that reports, sets, or varies a device identifier, and no tool that presents a device as a different device.
  • No account isolation features. Nothing here is built to keep separate accounts from being associated with each other.
These are deliberate boundaries rather than gaps. Network and identity concerns belong to the application layer above, not to the device control plane. If you need them, this surface is not where they live. They belong to the hosted product, and these docs do not cover it.

​
It is not a test automation platform

The primitives here are a device, a lease, an action, an observation and a receipt. A regression testing product is built out of more than that, and several of the pieces are missing:
  • No pass or fail assertion primitive. A run reports succeeded, failed or needs_user_control, and the first of those means the worker reported the goal reached. There is no assertion language and no deterministic verdict.
  • No batch or matrix. One call addresses one device, and there is no fan out across a device set. Scheduling and waiting do exist: a schedule fires a run on a cron expression or an interval, and a firing that finds no device free waits rather than failing, with later firings folding into the one waiting. What is still missing is running one goal across many devices at once.
  • Managed apps only. Install approved builds from the Console App Store. Customer APK uploads, custom app libraries and arbitrary URL installation are retired. Installation history and the apps currently on a phone remain readable.
  • No run that survives a restart. See Agent tier.
If what you want is a managed regression service rather than an API, that is a different conversation and phonebase.co is where to start it.

​
It does have a self serve entry

You can sign in, buy a device, drive it from a browser, mint an API key and give the device back, without talking to anybody. See The console and Buy, drive and return a device. Two things are genuinely narrower than “self serve” suggests, and both are boundaries rather than gaps:
  • Buying and returning need an org admin and a signed in session. An API key cannot start a purchase or return a device, and a member cannot commit the org to a subscription. Both answer 403.
  • Only one billing mode is on the price list. GET /v1/skus publishes one entry per pair this deployment holds a configured price for, and no per minute pair is published today. See Billing modes.

​
It has no spend cap

No dollar limit and no minute limit. Nothing stops when a number is reached. There is an optional email that tells you the next invoice has passed a level you set, and telling you is all it does. The limits that do stop something are the lease expiry and a run’s own budget, and they are collected on Spending controls.

​
It does not video record a session

Frames are stored. Every frame a run captures is kept in private object storage for as long as your organisation is, and two endpoints read them back. See Frame retention. What you get is the frames, one per step, addressed by run or by receipt. Not a video, not a scrubbable timeline, and not a recording of anything the agent did not look at: a frame exists because something asked for one. Continuous screen capture is not what this is.

​
What it is

Worth restating after all of that. One interface that reaches an emulator, a cloud Android device, real Android hardware, and a real iPhone driven by a mechanical actuator, with the same tool calls and the same normalized coordinates. Every action comes back as a receipt you can look up, every observation can be bound to the frame you decided on, that frame is still there when you go looking for it, and a retry under the same key replays its recorded outcome instead of pressing the glass twice. That is a narrow product on purpose. See Quickstart.