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 (within organization) - Requests are throttled per user/service account within a specific organization. The same principal operating in different organizations has separate rate limit quotas.

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 (within org)`	500

How Rate Limits Apply

Both rate limits are evaluated for each request: - A principal can make up to 500 requests per minute within their organization - All principals in an organization combined can make up to 1000 requests per minute - The most restrictive limit applies first

Example: If Principal A has already made 500 requests in the current minute, their next request will be rate-limited even if the organization has only used 600 of its 1000 requests.

Note: IT Asset Management has a Requests Per Minute (RPM) limit of 50.

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 should:

Implement exponential backoff when receiving 429 responses
Monitor the retry-after header to determine when to retry
Design your application to stay within the rate limits by batching requests when possible

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 100 invalid/unauthenticated requests and 200 non-org-scoped requests are NOT subject to these rate limits as they don't have an org-id associated.
John Doe's per-principal limit (within ACME org) will be left with 310 requests in the next 10 seconds (500-190 = 310 requests) before getting throttled for ACME organization.
ACME organization's limit 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 more org-scoped requests in the next 10 seconds before the entire ACME organization gets throttled.
If John Doe operates in a different organization, they will have a separate 500 RPM quota for that organization.
Other organizations with org ID different from ACME's will not have their limits affected.