Rate Limiting
Rate limits are defined to mitigate Denial of Service (DoS) attacks and excessive API calls that overwhelm the infrastructure.
In Flexera One APIs, rate limits are divided into the following categories
- per org - Requests are throttled per organization. Any org-scoped request
(i.e., request path containing
/orgs/<orgId>) belongs to this category. - per principal - Requests are throttled per user/service account. Any authenticated request from a user or service account belongs to this category.
- per client IP - Requests are throttled using client's IP address.
A request originating from a specific remote IP that passes authentication and is scoped to an org counts towards all the above categories.
The limits are calculated as Requests Per Minute (RPM). The following table shows the current rate limits
| Category | Rate Limits (RPM) |
|---|---|
per org |
1000 |
per principal |
500 |
per client IP |
500 |
Handling Rate Limits
Flexera One APIs return special headers in the response to help clients handle rate limits.
For every request that is NOT throttled, the response will contain the following headers
| Response Header | Description |
|---|---|
x-ratelimit-remaining |
number of requests remaining in the current limit window |
For every request that is throttled, the response will be a HTTP 429 status
code with the following headers
| Response Header | Description |
|---|---|
retry-after |
seconds after which the rate limit window will reset |
The clients making API requests can keep track of the number of requests
remaining in the current limit window using the x-ratelimit-remaining header.
If the client is throttled, i.e., gets a HTTP 429 response, then it can wait for
the duration returned in retry-after header before making further requests.
Understanding Rate Limits
This section illustrates how the rate limits are applied with an example.
Let's say a user "John Doe" from organization "ACME" makes the following requests in 50 seconds
- 100 invalid/unauthenticated requests
- 200 requests authenticated using the user's bearer token that are NOT org-scoped
- 190 requests authenticated using the user's bearer token that are org-scoped
Now,
- The remote IP from where John Doe is making requests will be left with
10 requests in the next 10 seconds (
500-100-200-190 = 10 requests) before getting throttled. - John Doe's bearer token will be left with 110 requests in the next 10 seconds
(
500-200-190 = 110 requests) before getting throttled. - ACME, the organization, will be left with 810 requests in the next 10 seconds
(
1000-190 = 810 requests) before getting throttled, i.e., John Doe's colleagues can make up to 810 requests in the next 10 seconds before the entire ACME organization gets throttled. - Other organizations with org ID different from ACME's will not have their limits affected.