Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Automation 360 Control Room API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fautomationanywhere.com%2Fautomationanywhere" | shStep 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fautomationanywhere.com%2Fautomationanywhere" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
What an agent can do with Automation 360 Control Room API.
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
GET STARTED
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
Patterns agents use Automation 360 Control Room API for, with concrete tasks.
★ 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.
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.
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.
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.
List recent activities, identify the failed run, then GET /usermanagement/users/{userId} and /devices/list to gather context for the on-call summary
16 endpoints — jentic publishes the only available openapi specification for automation 360 control room api, keeping it validated and agent-ready.
METHOD
PATH
DESCRIPTION
/authentication
Authenticate and obtain a bearer token
/automations/deploy
Deploy a bot to a runner
/schedule/automations
Create a schedule for a bot
/repository/files/list
List bots in the repository
/activity/list
List bot activities
/audit/list
Query Control Room audit logs
/usermanagement/users/list
List Control Room users
/credentialvault/credentials/list
List credential vault entries
/authentication
Authenticate and obtain a bearer token
/automations/deploy
Deploy a bot to a runner
/schedule/automations
Create a schedule for a bot
/repository/files/list
List bots in the repository
/activity/list
List bot activities
/audit/list
Query Control Room audit logs
/usermanagement/users/list
List Control Room users
/credentialvault/credentials/list
List credential vault entries
What agents get from Jentic-routed access to this vendor.
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 isolation
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.
Intent-based discovery
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.
Alternatives and complements available in the Jentic catalogue.
Specific to using Automation 360 Control Room API through Jentic.
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.
Know of an official OpenAPI document? Contribute it →
For 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.
Use for: Deploy a bot to a specific runner device, List all bots in the Control Room repository, Schedule a bot to run every weekday at 8am, Find audit log entries for a user in the last 24 hours
Not supported: 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.
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.