- 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 and large data fields usage optimization
- 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 and large data fields optimizations 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 |
Examples |
Limits |
Effective since |
|---|---|---|---|
|
|
|
100 API requests/minute/tenant |
July 2024 |
|
|
| 100 API requests/minute/tenant | July 2024 |
GET/odata/Jobs(<job_id>) is not rate limited.
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/JobsorGET /odata/QueueItemsendpoints)
Retry-after response header, meaning that they perform automatic retries of Orchestrator operations. Please make sure to always use the
latest version of System activities to benefit from this.
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.
- Make sure you always use the latest version of System activities.
- 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.
Jobs - 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.ExportSee Exporting jobs for details. |
Community and Canary tenants: March 2024 Enterprise tenants: July 2024 |
GET /odata/Jobs endpoint, 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.
GET/odata/QueueItems endpoint is optimized by applying these size limitations to its fields:
|
Field |
Limit | Effective since |
How to tell that you are impacted |
How to address this |
|---|---|---|---|---|
Progress |
1,048,576 characters |
> Community and Canary tenants: April 2024 > Enterprise tenants: May 2024 |
A specific error message is returned. |
We recommend that you use storage buckets and/or Data Service blob storage if you need to store more data. |
|
104,857 characters |
All tenants: September 2024 | |||
AnalyticsData |
10 KB |
> Community and Canary tenants: June 2024 > Enterprise tenants: September 2024 |
Enterprise: If your current data load exceeds these limits, we will send monthly reports to administrators. | |
Output |
100 KB | |||
SpecificData |
500 KB | |||
ProcessingException - Reason |
102,400 characters | |||
ProcessingException - Details |
102,400 characters |
The following filter is also limited for performance purposes:
|
Filter |
Limit |
Effective since |
How to tell that you are impacted |
How to address this |
|---|---|---|---|---|
|
|
> If you do not use the
$top filter, you receive 100 records by default.
> If you use the
$top filter, you receive a maximum of 100 records. Anything exceeding 100 triggers a 400 Bad Request error message.
|
> Community and Canary tenant: June 2024 > Enterprise tenants: September 2024 |
Enterprise: We aim to send an email notification to administrators if we detect the usage of this filter in API calls. However, we ask that you keep a close eye on your end as well. |
We recommend that you modify your process or API usage logic accordingly if you expect to exceed this limit. |
Jobs and QueueItems 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.
