canonical: https://jentic.com/apis/automationanywhere.com/automationanywhere

# Automationanywhere Automation 360 Control Room API

Jentic publishes the only available OpenAPI specification for Automation 360 Control Room API, keeping it validated and agent-ready. Automation 360 is Automation Anywhere's RPA platform, and the Control Room API is the programmatic surface for everything that runs inside a Control Room: bots, deployments, schedules, devices, users, roles, audit logs, the credential vault, and workload queues. Most listing endpoints use POST with a JSON filter body rather than GET so callers can express complex multi-field filters and pagination in one request. Authentication is a bearer token issued by /authentication and refreshed via `/authentication/token.`

## For AI agents

Authenticate with a Control Room user, then deploy bots, schedule runs, manage users, roles, and credentials, query audit logs, and inspect devices and workload queues - the full Control Room surface as a tool list.

## Scope

Does not handle bot authoring or recording, runner installation, or non-RPA workflow design - use for Control Room operations: deploy, schedule, audit, and user/role management only.

## Capabilities

- Authenticate with username and password (or API key) via POST /authentication and refresh tokens at `/authentication/token`
- Deploy a bot to a runner via POST `/automations/deploy` with a bot file ID and target devices
- Schedule recurring bot runs via POST `/schedule/automations`
- List bots, activities, and workload queues using POST `/repository/files/list`, `/activity/list`, and `/workload/queues/list`
- Manage users, roles, devices, and credentials with the /usermanagement, /credentialvault, and /devices endpoints
- Query audit logs for compliance via POST `/audit/list` with filter criteria
- Create, update, and delete users and roles for granular Control Room access

## Use cases

### CI/CD-style bot deployment

Treat Automation 360 bots like build artefacts: a CI pipeline authenticates with /authentication, lists the bot file in `/repository/files/list` to confirm the version, and POSTs to `/automations/deploy` with the chosen runner device. Activity status is then polled via `/activity/list.` This replaces manual Control Room clicks with a reproducible, audit-friendly pipeline.

Example prompt: After authenticating, POST `/automations/deploy` with fileId and runAsUserIds to launch the bot, then poll `/activity/list` for the deployment's status

### Scheduled batch run governance

An ops team manages overnight RPA workloads through the API instead of the UI. `/schedule/automations` creates each cron-like schedule, `/workload/queues/list` reports queue depth, and `/audit/list` provides the trail compliance reviewers need. When a runner fails, the team uses `/devices/list` to pivot to a healthy runner and re-deploy.

Example prompt: POST `/schedule/automations` with a cron expression and a target bot file, then poll `/workload/queues/list` to confirm executions land in the queue

### Compliance and audit reporting

Compliance teams pull Control Room audit data into a SIEM by calling POST `/audit/list` with a date range and event-type filter, then storing the result for retention. Pairing this with `/usermanagement/users/list` and `/usermanagement/roles/list` makes user-access reviews routine: identify who held which role on a given date and what they did during that window.

Example prompt: POST `/audit/list` with filter on user_id and a date range, then export the results to the compliance store

### Agent-driven operational triage

An on-call AI agent investigating a failed automation can list recent activity, find the failed run, and inspect the device and the user that launched it - all via the Control Room API. Through Jentic the bearer token lifecycle is managed inside the credential vault, so the agent does not need to call /authentication or `/authentication/token` directly.

Example prompt: List recent activities, identify the failed run, then GET `/usermanagement/users/{userId}` and `/devices/list` to gather context for the on-call summary

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/authentication` | Authenticate and obtain a bearer token |
| POST | `/automations/deploy` | Deploy a bot to a runner |
| POST | `/schedule/automations` | Create a schedule for a bot |
| POST | `/repository/files/list` | List bots in the repository |
| POST | `/activity/list` | List bot activities |
| POST | `/audit/list` | Query Control Room audit logs |
| POST | `/usermanagement/users/list` | List Control Room users |
| POST | `/credentialvault/credentials/list` | List credential vault entries |

## Key resources

- **Authentication** — Issue and refresh bearer tokens
- **Bots** — List bots and inspect repository files
- **Deployments** — Deploy bots to runners and track status
- **Schedules** — Create and manage scheduled bot runs
- **Activities** — Query the activity history of bots
- **Users and Roles** — Manage Control Room users and role assignments
- **Credential Vault** — List and manage credentials available to bots
- **Devices and Workload** — Inspect runners and workload queue state
- **Audit** — Query Control Room audit log entries

## Why Jentic

- **Setup:** Wiring the Automation 360 Control Room API by hand means obtaining a bearer token from POST /authentication, refreshing it at `/authentication/token` before expiry, pointing every call at your own Control Room host, and learning the POST-with-filter-body listing pattern most endpoints use. Through Jentic you install once, import the Automation 360 Control Room API from the API Directory, store your Control Room username and password once, and your agent calls it.
- **Permission scoping:** The Control Room expresses listing filters and deployment targets in the request body rather than in the URL path, so scope your agent to the operations it needs: for example allow `/repository/files/list` and `/activity/list` for read-only triage. You choose the operations it may call, so `/automations/deploy` or user and role changes under /usermanagement are not included unless you add them.
- **Credential handling:** Your Control Room username and password are stored once, encrypted, by your own Jentic One instance and the bearer token is minted server-side at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'deploy an Automation 360 bot to a runner' or 'query Control Room audit logs', and Jentic returns the matching POST operation like `/automations/deploy` or `/audit/list` with its filter-body schema so the agent calls it without navigating the Control Room reference docs.

## Related APIs

- **n8n API** — n8n is an open-source workflow automation tool with a similar deploy and run surface
- **Zapier NLA API** — Zapier offers SaaS-to-SaaS automation without the enterprise governance layer
- **ServiceNow API** — ServiceNow tickets often trigger Automation 360 bot runs

## FAQ

### Why is there no official OpenAPI spec for Automation 360 Control Room API?

Automation Anywhere publishes HTML reference docs but not a downloadable OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Automation 360 Control Room API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Automation 360 Control Room API use?

The Control Room issues a bearer token from POST /authentication when called with a username and password (or apiKey). Refresh the token at POST `/authentication/token` before it expires. Through Jentic the username and password are held in the credential vault and the bearer token is minted server-side per call.

### How do I deploy a bot through the Automation 360 Control Room API?

After authenticating, list the bot file with POST `/repository/files/list`, take its fileId, and POST `/automations/deploy` with the fileId and an array of runAsUserIds. Track the resulting deployment via POST `/activity/list` filtered on the returned deployment id.

### Can I query Control Room audit logs through the API?

Yes. POST `/audit/list` accepts filter criteria such as date range, user, and event type, and returns paginated audit entries. This is the route compliance teams use to feed Control Room audit data into a SIEM.

### How do I schedule a bot run through Jentic?

Search Jentic for 'schedule a bot run', load POST `/schedule/automations`, and execute it with a cron expression and the target bot's fileId. Jentic mints the bearer token from your stored Control Room credentials. Get started with Jentic One, the self-hosted execution layer.

### What are the rate limits for the Automation 360 Control Room API?

Automation Anywhere does not document fixed rate limits in the spec; throughput depends on Control Room sizing and concurrent runner capacity. Treat list endpoints as throttled and use the filter body to narrow results rather than polling broadly.

### Can I limit what my agent is allowed to do with the Automation 360 Control Room API?

Yes. Because Jentic One is self-hosted, your own rules decide which Control Room operations and credentials the agent may use, so you scope it to exactly the calls it needs. For read-only triage you can allow POST `/repository/files/list` and POST `/activity/list` while leaving out state-changing operations. That means `/automations/deploy` and the user and role changes under /usermanagement stay off limits unless you explicitly add them.