Clarification on Rate Limiting for Jira REST API's Edit Issue Endpoint

[Vivek Chauhan]

I'm currently utilizing the Jira REST API to edit issue and have encountered some inconsistencies regarding rate limiting. Some official documentation mentioned a limit of 500 requests per 5 minutes. However, in practice, I haven't received 429 errors even after making 600 requests within this timeframe. Conversely, when making concurrent API calls, I occasionally encounter 429 errors.

Could someone provide clarity on the exact rate limiting parameters for the Update Issue API? Is there a difference in rate limiting when requests are made concurrently versus sequentially? Additionally, are there specific thresholds or conditions that trigger the 429 errors?

Understanding the precise rate limiting behavior would greatly assist in optimizing our application's interaction with the Jira API.

[Vishal Biyani]

@Vivek Chauhan 

if you refer to this article it will give better clarity.

See if this helps

[Vivek Chauhan]

I have read that document, but no exact rate limits are mentioned in there. And i want the exact rate limits to handle 429 error in my app.

[Julian Coira]

hope this helps someone that ends up here like me lol

https://developer.atlassian.com/cloud/jira/platform/rate-limiting/ 

429 responses may be accompanied by Retry-After and X-RateLimit-Reset headers.

Retry-After indicates how many seconds the app must wait before reissuing the request. If you reissue the request before the retry period expires, the request will fail and return the same or longer Retry-After period.

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. It's provided in the format: yyyy-MM-ddTHH:mmZ.

Some transient 5XX errors are accompanied by a Retry-After header. For example, a 503 response may be returned when a resource limit has been reached. While these are not rate limit responses, they can be handled with similar logic as outlined below.

Other header responses include:

• 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.

• 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-based, which refers to API rate limits being breached

  • jira-burst-based, which refers to API burst rate limits being breached

  • jira-per-issue-on-write, which refers to per-issue write rate limits being breached

• X-RateLimit-NearLimit: When true, indicates that less than 20% of any budget remains. This is a boolean value added to a successful response.