Control Room APIs

The Automation Anywhere Control Room provides APIs that enable you to customize how you (and your automations) interact with Automation Anywhere.

Important:
  • From Automation 360 v.34, the following WLM API endpoints are deprecated and are planned to be discontinued (EoL) along with the v.38 release :
    • POST /v3/wlm/workitemmodel
    • GET /v3/wlm/workitemmodels/{id}
    • GET /v3/wlm/queues/{id}
    • POST /v3/wlm/queues/{id}/consumers
    • POST /v3/wlm/queues/{id}/participants
    • PUT /v3/wlm/queues/{id}/members/{userId}
    • POST /v3/wlm/queues/{id}/file
    • PUT /v3/wlm/queues/{id}/workitems/{workItemId}
    Replace the above API endpoints with the following API endpoints:
    • POST /v4/wlm/workitemmodel
    • GET /v4/wlm/workitemmodels/{id}
    • GET /v4/wlm/queues/{id}
    • POST /v4/wlm/queues/{id}/consumers
    • POST /v4/wlm/queues/{id}/participants
    • PUT /v4/wlm/queues/{id}/members/{userId}
    • POST /v4/wlm/queues/{id}/file
    • PUT /v4/wlm/queues/{id}/workitems/{workItemId}
  • From Automation 360 v.34, the Bot Scheduler API endpoints: /v1/schedule/automations are deprecated and are replaced with /v2/schedule/automations. The v1 version is planned to be discontinued (EoL) along with the v.38 release

You can view and navigate to all the Control Room API modules and the associated endpoints in the following API reference sections.

The different API versions below represent different iterations of APIs over time. As an API evolves, new features or improvements are introduced. To manage these changes and maintain compatibility with existing applications, developers use versioning.

v1 Endpoints

v2 Endpoints

v3 Endpoints

v4 Endpoints

Modules Description
Bot deploy API (V4) Use the v4 Bot Deploy API to deploy bots from the public workspace to Bot Runner devices.
Workload Management API Use the v4 Workload Management (WLM) APIs to programmatically manage and create work item models, queues, work items, and automations in your Control Room.
Migration API (Bot migration) Use the v4 migration APIs to migrate TaskBots and MetaBots that were created in Enterprise client versions Enterprise 11 and Enterprise 10 to Automation 360.
Note: To avoid errors and ensure smooth processing of your requests, remember that all JSON parameter names are case-sensitive. For more information, refer to the relevant sections of the API reference documentation for clear guidelines and examples to help you construct your queries and request bodies with the correct casing.

Getting started with Control Room APIs

All requests must include an X-Authorization header with the JSON authentication token, or an Authorization header with a Bearer token for requests to the Control Room. The following sections provide details about the Control Room APIs available endpoints, methods, resources, authentication protocols, parameters, and headers, as well as examples of common requests and responses.

Note: The Bearer token is supported as of the Automation 360 v.27 release and later. It is unsupported and ignored in any previous releases. You must obtain the Bearer token from our OAuth services. To authorize your access, use either X-Authorization (using Authentication API) or Authorization (using OAuth). You cannot use both in the same API.
You can use Control Room Swagger documentation to view and run the APIs. Access the Control Room Swagger documentation by using the link https://{control-room}/swagger/ and replace {control-room} with your Control Room instance. The following sections provide useful information about how to write a Control RoomAPI request:

API deprecation policy

API deprecation indicates that an API is no longer recommended for use but is functional. Developers are encouraged to migrate to newer, supported versions of the API. The API will be available till the End of Life (EoL) date and the release version to enable a smooth transition.

API EoL (End of Life) indicates the date and the release version when the API will cease to function, and will no longer be available for use. Developers should have completed their migration to the newer, supported versions of the API before this date.

The following scenarios may require deprecating APIs:

  • Security vulnerabilities: Older API versions contain known security vulnerabilities that have been fixed in newer versions.
  • Technical debt: Older API versions can be built on outdated technologies, approaches or frameworks that are no longer supported, making maintenance or enhancements difficult.
  • Performance: Older API versions are not optimized for modern use cases or increases in scale, leading to poor performance and slower response times.
  • User experience: Deprecated API versions contain confusing or redundant endpoints that can make it difficult for users to navigate.

APIs will be supported for a minimum period of 2 years. After 2 years, an API deprecation may be announced with the API being available for at least one more year (four releases) to provide you with sufficient time to move to the newer version.

Note: The above policy will not apply for deprecation due to security vulnerabilities on public APIs. In such cases, immediate action is required to mitigate risks and we will make every effort to communicate this change to you as soon as possible.