Update March 13, 2025:
To ensure Marketplace partners are able to decipher whether or not they’re facing actual rate limits, we have rolled out beta- prefixed headers. These will appear to notify partners that they would have breached the upcoming quota and burst based rate limits. The headers will be as follows:
Beta-Retry-After
X-Beta-RateLimit-NearLimit
X-Beta-RateLimit-Reason
X-Beta-RateLimit-Reset
However, if you do receive headers without beta-, be advised that you are facing rate limits.
What is it and why are we doing it?
We have recently noticed an unusual increase in API usage. In order to maintain reliable services for both Atlassian customers and partners, we will begin enforcing more granular rate limits for Confluence and Jira APIs.
When is it happening?
We will begin enforcing REST API (Quota and Burst based) rate limits for all free apps on or after August 18, 2025. We have added additional headers to provide further transparency. Please monitor relevant header responses listed in the section below.
In some circumstances whereby apps are highly impacting the stability of our platform, we reserve the right to enforce the limits at an earlier date. We will notify your listed contact via email if you are impacted.
What do Marketplace partners need to do?
ACTION RECOMMENDED
We recommend all vendors monitor header responses
Header responses for Jira and Confluence:
Retry-After: This header indicates the amount of time (in seconds) the user should wait before making another request, once they have hit the rate limit.
X-RateLimit-Reset: This header provides the timestamp (in ISO 8601 format) when the rate limit will reset, calculated as the request timestamp plus the Retry-After period.
X-RateLimit-Limit: This header specifies the maximum number of requests that a user can make within a specific time window.
X-RateLimit-Remaining: This header shows the number of requests remaining in the current rate limit window before the limit is reached.
Jira-specific header responses:
RateLimit-Reason: This header indicates the reason the request was declined. Possible values:
JIRA_COST_BASED which refers to counter and cost based limits being breached
JIRA_QUOTA_RATE_LIMITED which refers to API rate limits being breached
Please ensure your app is able to handle the header responses as required
Ensure you have an error message in place should rate limits be exceeded, as customers will see whichever error message you have in place to handle API status code 429 as per the API documentation. If you do not have this in place, we recommend the following message:
“This app has reached the limit of allowed API requests. Please try again later.”
Has Atlassian ever given consideration to making the rate limits proportional to the product plans? Or, is implementing that too technically impractical?
Hi @sunnyape I just wanted to confirm that by product plan you’re referring to free, standard, premium and enterprise? If so, the rate limits are already proportional to the plan.
@KelseyVanScoy can you please elaborate if Atlassian has done any research with regard to which endpoints are getting increased traffic and whether or not this has to do with recent API deprecations (Confluence V1 API and Jira V3 API endpoint)?
The marketplace partner community has repeatedly warned Atlassian that the lack of feature completeness in replacements for API deprecations would result in additional API calls being made. It would be good measure for Atlassian to investigate if this spike in traffic is indeed related to the warnings given by this community that weren’t heeded.
On this point there are also bugs in Jira that prevent me from using APIs efficiently! I have to make additional permissions requests because the permissions returned for JPD projects on the bulk endpoint are lies and I would have security vulnerabilities if I trusted them. https://jira.atlassian.com/browse/JRACLOUD-84541
So I’d also be curious where the problems actually are so we can work together to be more efficient rather than working against each other with strict rate limits. E.g. if you reduce my ability to make these inefficient permissions requests without fixing the root cause, you are fucking our mutual customers and blaming me for it. If you fix the bulk endpoint though, everybody wins.
@KelseyVanScoy Can you share any details about the impacted endpoints? I’m worried that this change could affect our app functionality because of the significantly higher number of requests caused by the design of the Confluence v2 API.
I ran a few tests with some endpoints, but none of the responses included any of the new headers mentioned above. Will the headers only be included in responses starting on August 18, 2025?
There’s another issue with rate limiting that I discovered when I ported one of our apps to the Confluence v2 API a few months ago. Requests made in the front-end of an app, e.g., a Forge iframe, are cross-origin requests. Therefore, the browser sends additional CORS preflight requests to the API. However, these requests are also rate-limited, which makes it impossible for front-end apps to implement the rate-limit handling described in the documentation. I reported this issue to developer support (ECOHELP-46824), but it was not resolved at the time.
Hi @remie thank you for reaching out and sharing your concern. This issue has existed since pre-Confluence/Jira API deprecations, and the thresholds we have set have been planned with those deprecations in mind. The team is actively monitoring where and from whom the spike in traffic is coming from to ensure that these spikes do not affect our shared customers.
@KelseyVanScoy I think you’ve misunderstood what I asked. I am asking if the rate limits can scale globally per plan type, not per user in that plan.
Currently, there is no way for any single user in an Enterprise plan to utilise the REST API any faster / more than any single user in the Free plan. This means that as a System Admin of a large Jira instance on the Enterprise plan, there is no way to complete very large scale changes of the environment via the REST API via a single user account any faster than if they were on the Free plan. Currently, the only way to improve this situation is to have multiple service accounts and use them concurrently to achieve the equivalent outcome of concurrent-tasking / pseudo multi-threading the process.
I’ve done a few very large scale changes for organisations that, even using this technique, the process still took close to two days to run because the service accounts had to have their individual actions throttled to stay within their limits.
It would be great if large organisations could have an option to buy higher rate limits either per user or per unlimited access special service accounts, or maybe even per interval / time period, which would allow them to get through API intensive changes as fast as possible. Modern cloud focused IT departments are accustomed to paying extra for load / period based pricing anyhow, so it’s just another “Pay more to get more” scenario for them.
The AWS infrastructure auto-scales to increase capacity to meet load increases, which incurs a cost to Atlassian that can be determined and therefore costed to their customers, but I also understand that Atlassian might not be prepared to provide a single compute cluster for one organisation just to be able to host their personal Jira or Confluence instance and give them that sort of special privilege and also be able to track the API load / usage and price that accordingly, as that would be a major change in the overall pricing structure.
On reflection, I suppose what I’m inferring is the same as asking to have Atlassin products being available on the equivalent of a Private Cloud plan.
Would it be possible to share some more insights on the issue? I agree with the other vendors in this thread that there is a chance that we’re making too many calls to your REST APIs because the APIs don’t serve us well enough. So I would really want to see an effort to fix the root cause and not the symptom.
I’d be interested to understand
Which REST APIs are most affected
If there’s any reason to believe a specific vendor/app is causing unusual amount of traffic, reach out to them
@KelseyVanScoy that would mean that the issue has existed for ~2 years?
If this is the case, how does that related to
We have recently noticed an unusual increase in API usage
It would be great if Atlassian can share more details here so that the partner community can elaborate on determining whether the increase use is coming from workarounds that we have implemented.
What is the reason to withhold more specific information about which endpoints are seeing spikes?
Just weighing in here with another example of what others have already highlighted. We are working on moving from the deprecated JQL search endpoint to the new one.
We used to get a paginated set of issues in a single request. Since in the new endpoint, the pagination concept changed completely, and the total issue count is not included anymore, we now have to do about three requests for what was one request before.
Atlassian may have solved their issues by offloading the problem to API users. In that sense, it would be good to understand which endpoints contribute to this announcement and ensure the root cause is addressed.
what would help as also would be a way to simulate the new enforcement limits. As of now, we would potential run into rate limiting issues on the enforcement date with no possibility to assess whether or not our app is affected by it. The retry-after headers etc are not sufficient to react to as in some instances the design of the app will be called into question entirely
Have there been some changes already implemented, also for non-free apps? Because we are seeing massively increased 429 responses from the APIs, e.g. from the user API:
“ratelimit-reason”: “JIRA_MAX_CONCURRENT_THREADS_ACROSS_ALL_INSTANCES_PER_TENANT_PER_USER”,
Atlassian started sending retry-after and retry-reason headers with 2xx response codes last week. Foolishly we weren’t checking the response code, so our rate limiting logic suddenly slammed the brakes on, unexpectedly impacting application functionality.
This is for a paid app. @KelseyVanScoy does this experience indicate that from August 18th (or earlier?!) our app will experience even greater rate limiting than it does now? Ie the 2xx responses that had retry-after headers last week will become 429 responses?
Hi all, thank you so much for sharing your questions and concerns. I am working with the team to get responses for each of you and will respond as soon as I can provide more clarity.
@tobias.viehweger@jbevan when headers were deployed last week, they seem to have impacted apps that should not have been impacted. We are very sorry that both of your apps were impacted. Can you both confirm that this issue is no longer occurring?
Is it possible to update Response handling pseudo code in the docs to consider X-RateLimit-Reset too? E.g. is X-RateLimit-Reset used for 429 responses only as stated in Rate limit related headers or may it be used in 5xx responses, too?
And it would be nice to update pseudo-code to show how to get some detail for handleFailure(...); from RateLimit-Reason of other header fields.
Also, some endpoint or local mockup service to test these rate limiting answers would be very handy. Now, we have to adjust our code by errors logs from production.
Today in logs, I got 404 for PUT method on an endpoint, that exist for 100%, one minute later, it worked. I am wondering if I got 404 instead of 429, but can’t verify it
