- Getting Started
- The Swagger Definition
- Examples using the Orchestrator API
- Alerts Requests
- Assets Requests
- Calendars Requests
- Environments Requests
- Folders Requests
- Generic Tasks Requests
- Jobs Requests
- Libraries Requests
- License Requests
- Packages Requests
- Permissions Requests
- Personal Workspaces Requests
- Processes Requests
- Process Data Retention Policy Requests
- Queue Items Requests
- Queue Retention Policy Requests
- Robots Requests
- Roles Requests
- Schedules Requests
- Settings Requests
- Storage Bucket Requests
- Tasks Requests
- Task Catalogs Requests
- Task Forms Requests
- Tenants Requests
- Transactions Requests
- Users Requests
- Webhooks Requests
Rate limits
- They ensure a predictable system: knowing the API call limit helps in better designing and maintaining your applications. It provides a predictable environment, minimizing surprises due to unexpected limit breaches.
- They improve performance: by controlling the traffic on our servers, we ensure optimal performance and quicker responses, significantly improving your product experience.
- They enhance security: the limits outlined below act as an additional layer of security, protecting your system from potential cyber threats.
- They ensure fair usage: our rate limits assure equitable resource allocation to all users, and smooth operation even during peak use periods.
The limits outlined below require some adjustments on your end, but we are confident that they will bring long-term benefits.
These are the limits we enforce:
Endpoint |
Limits |
Effective since |
---|---|---|
|
100 API requests/minute/tenant |
July 2024 |
| 100 API requests/minute/tenant | July 2024 |
It is important to note that these limits do not apply to adding queue items and processing jobs. As such, there is no impact on adding a queue item, removing it from a queue, setting its status, or on starting and processing any number of jobs.
You can check your API usage per month or day on the tenant-level API audit tab in the Monitoring window.
Header |
Description |
Example |
---|---|---|
|
All requests beyond the aforementioned limits are returned an HTTP 429 response which includes this header. It displays the number of seconds that you need to wait until the endpoint is available to you again. |
Retry-After: 10 means that the rate limit on the endpoint expires in 10 seconds. Any retries within these 10 seconds result in a 429 response.
|
|
The number of calls remaining |
X-RateLimit-Remaining: 30 means that you have 30 calls remaining in the current time range
|
If the number of requests per minute is below 10, it is rendered as 0.
The following activities are impacted by these limits:
- Get Job
- Get Queue Items
- Orchestrator Http Request (when used to
call the
GET /odata/Jobs
orGET /odata/QueueItems
endpoints)
This is what we recommend you do to make sure that you both comply with our limits and take full advantage of them:
- Review your API usage patterns and the information you retrieve from our previously mentioned
GetAll
-type endpoints. - Adjust your API call frequency and data extraction procedures to align with these limits where necessary.
- See the Exporting jobs and Exporting queue items sections for examples on how to retrieve jobs and queue items data.
- Use the Insights real-time data export option.
- Get in touch with your account manager or our support team if you have any questions or need further clarification.
The API endpoints used for retrieving lists of jobs and queue items can prove problematic when used for real-time monitoring and data export. For example:
-
When requesting up to 1.000 items, with each item amounting to up to 1 MB of large data, the response to a single API call can be 1 GB in size. Since there are intermediaries that do not allow responses of this size, requests fail.
-
When using complex filters, then paginating a queue with multi-million queue items, requests might start timing out after a few dozen pages. This is due to the amount of data that needs to be retrieved from the database.
GetAll
endpoint responses. These are the impacted fields:
Endpoint |
Omitted fields |
What you can use instead |
Effective since |
---|---|---|---|
|
|
For exports, use the dedicated endpoint:
GET/odata/Jobs/UiPath.Server.Configuration.Data.Export See Exporting jobs for details. |
Community and Canary tenants: March 2024 Enterprise tenants: July 2024 |
|
|
For exports, use the dedicated endpoint:
/odata/QueueDefinitions
({key})/UiPathDataSvc.Export See Exporting queue items for details. |
Community and Canary tenants: March 2024 Enterprise tenants: July 2024 |
GET /odata/Jobs
or GET
/odata/QueueItems
endpoints, either via API or via the Get Jobs,
Get Queue Items, or Orchestrator HTTP Request activities, you need to
find out whether you use any of the listed fields. If you do, please be aware that the
content of these fields will be returned as null.
We recommend that you test out processes in your Canary tenants to assess the impact.
You can use the following alternatives to retrieve the fields:
- See the Exporting jobs and Exporting queue items sections for examples on how to retrieve jobs and queue items data.
- Use the Insights real-time data export option.
- Get in touch with your account manager or our support team if the previous methods do not work for you.
Rate limits and large data fields changes will not be implemented in on-premises environments.
If you are using standalone Orchestrator and are thinking of moving to cloud, you can use the IIS request logs to determine the request rate for the impacted endpoints. The analysis depends on how you aggregate the logs, for which you can use, for instance, Microsoft Log Parser.
For assessing the impact on large data fields, we recommend testing out your processes in Canary tenants.