Out of 22 Automation Anywhere API pages on apis.io, the Deployments API is the one that matters most, and it is a single operation. POST /automations/deploy takes a bot from the public workspace and starts it on one or more Bot Runner devices. The rest of the Control Room surface, including credential lockers, work-item queues, roles and audit data, exists to support that one call.
Automation Anywhere scores 74.6 on the Kin Score, exemplar. Its Agent Readiness is 52.4, agent-ready, gated down from agent-native. The provider record counts 7 published APIs, and the catalog splits them into the 22 pages.
What the one operation carries
The contract is OpenAPI 3.2.0 at version v4, served from https://{controlRoomUrl}/v4 with a default of your-control-room.automationanywhere.com. Each customer runs its own Control Room, so the host has to be a template. Auth is a bearer JWT or an X-Authorization header.
The request body is where the design work is. One endpoint supports three execution modes:
| Mode | Request object | What runs it |
|---|---|---|
| Unattended | UnattendedRequest |
Devices tied to runAsUsers, or a device poolIds list |
| Attended | AttendedRequest |
The logged-in user’s device (currentUserDeviceId) |
| Headless | HeadlessRequest |
numOfRunAsUsersToUse On-Demand Bot Runners in parallel |
Runtime inputs go in botInput as typed variables (STRING, NUMBER, BOOLEAN, LIST, DICTIONARY, DATETIME, CREDENTIAL). A CallbackInfo object takes a webhook URL and headers to notify when the run finishes. The response returns a deploymentId. The contract documents 200, 400, 401, 404 and 500 responses.
The tension
The API page says this surface is for “Deploy bots to Bot Runner devices and monitor deployment status.” The contract has the deploy and does not have the monitoring. There is no status operation in it. You either pass a callback or take the deploymentId to another part of the Control Room API.
The bigger gap is that the provider’s Agent Readiness record marks idempotency and reversibility both unlit, and there is no dry-run mode. For most APIs that is a small mark against them. Here, one call starts software robots that log into systems with stored credentials and act on them. If an agent retries after a timeout, it may start the same bot twice on headless runners that scale in parallel, and nothing in the contract prevents that or tells the agent how to undo it. Error semantics are verified, so a failed call gets a clear answer. A call that succeeds twice gets no answer at all.
A note on our side: the provider’s agentic-access dimension is lit as derived, which means we generated it, so I do not credit Automation Anywhere for it.
Takeaway
Two additions would change how this endpoint reads to an agent: an idempotency key on POST /automations/deploy, and a status operation in the same contract so deploy and monitor ship together. The modes are well modeled. What the contract is missing is protection against starting a run by accident.
Read the contract on apis.io and Automation Anywhere’s Control Room API docs.