What is the rate limit value for the api calls made to Jira?

, , ,
1

We have been facing issue with the api rate limits recently.

We would like to know what is the rate limit count today for the api calls that are made to Jira, assuming the rate limit is managed at the level of tenant/user/app-user.

Also, is there any recent change that Jira has made regarding the api rate limits ?
We do see that the document has updated recently.
https://developer.atlassian.com/cloud/jira/platform/rate-limiting/?_ga=2.105859072.2068921315.1605000191-1043247589.1599447605

Thank you,

1 Like
2

Can you explain what the issue is? Does your code already back-off after receiving HTTP status 429?

As explained in the documentation to which you linked:

In short, we can’t give you a simple number of as a request rate because the limits aren’t based on your assumption of tenant, user, and/or app-user.

The new documentation is our attempt to document a previously opaque topic, not a change in the technology. That said, our site reliability engineers do sometimes apply additional limits if they detect something they consider to be API abuse. This can mean an app that was making, for example, 20 API requests per second, is suddenly capped to, for example, 2 API requests per second. These additional limits are applied per tenant. The best way to resolve such a case is to first implement the rate limiting precautions listed in the rate limit documentation, then work with your customer through Atlassian support to remove the abuse flag.

1 Like
3

Since this topic has been around for a while, I’d like to revisit it with a narrower focus:
Are there now any concrete numbers or guidelines for API rate limits when calling requestJira asApp in Forge?

I understand that Jira Cloud uses a cost-based rate limiting model, and that calls made using asApp() are evaluated against the “App” quota, which appears to have a baseline of 10 requests per second per tenant.

However, it’s still unclear what the safe thresholds are for things like:

  • Sustained request rates over time (e.g., per minute)
  • Behavior under burst conditions
  • Whether retry windows vary per endpoint or tenant tier

For example, when performing batch issue updates via requestJira asApp, it’s difficult to confidently avoid hitting 429 Too Many Requests without explicit quotas or throttling guidance.

So my question:
Is there now an official, reliable number (or formula) to calculate safe throughput for asApp() calls per app per tenant?
Even a conservative figure like “safe to stay under X req/min” would help when designing update-heavy flows.

Or is there new documentation that provides more clarity on this?

1 Like