Hi all, thanks for the detailed and thoughtful questions.
We will first address some common themes and then return to other individual questions in this thread.
We understand the question about why this doesn’t follow a longer changeover period. Over the past year, we’ve seen a significant increase in overall API usage, which drives important business outcomes. We have also observed an increase in policy violations that can affect the experience of all other apps in our ecosystem. Throughout last year, we have been adjusting our rate limits policy, and we have made a few announcements regarding the plan to introduce rate limits, as well as started selectively enforcing rate limits on some apps.
-
Along with introducing the point-based rate limits, our goal is to support a smooth transition for all apps and minimize impact. Based on our traffic analysis for the past year, ~95% of the apps never cross boundaries of the Global Pool; of those that did, we proactively moved qualifying apps to Tier 2. We don’t expect the vast majority of apps to experience any impact from this change.
-
We have been sending Shadow headers, to apps to notify them if they exceed the new rate limits. The updated quota-based rate-limited headers will clearly indicate which limits (Global or Per-Tenant) are being reached. Additionally, enforcement will be phased in gradually across different app cohorts starting. This approach enables us to closely monitor the rollout and minimize any potential impact.
Other themes in the questions.
Hourly accounting and burst behavior
The hourly quota is intended as an accounting boundary, not as a guarantee that an app will be unavailable for a full hour if a spike occurs.
- The model will forgive occasional hourly spikes for the app; however, when the app consistently crosses the Global Pool thresholds, please explore optimizing API usage patterns. Additionally, please apply for the Tier 2 quota. We recognize that apps can experience short, high-intensity bursts, so that short-lived spikes don’t translate into prolonged service disruptions for all other tenants.
A design that results in hour-long lockouts for apps would not be acceptable, and this is one of the key scenarios we’re pressure-testing during this period before enforcement.
- We are already sending shadow headers to inform you about whether your app is hitting rate limits. The developer console change, which lists app tiers, will go live next week.
Tier 2 escalation path
We have proactively reviewed and moved qualifying apps that require higher quotas than the Global Pool to Tier 2.
- If your app consistently generates high traffic or you expect your usage patterns to increase and potentially exceed the threshold in the near future, we encourage you to contact us to review your app for Tier 2 quotas, which can help prevent any potential disruptions. The current escalation path for requesting additional capacity is via a support ticket in the Partner Portal. Increase Marketplace App Limits.
- During an active review, the app will receive a grace period so that the app’s customers are not affected.
Our goal with this rollout is to ensure minimal impact on apps, with thresholds derived from existing traffic, and no immediate functional changes should be required for most apps. The only expected developer action is to observe the new rate-limit headers and ensure standard retry/backoff handling is done.
Thanks for flagging this - “ Each request must stay within the maximum…” In the current model, requests are evaluated only against the hourly quota. There is no independently configurable or enforced per-request cap that developers need to account for. We’ll update the documentation to remove or rephrase this wording to avoid confusion.
Thank you all for sharing your feedback and concerns regarding the upcoming point-based rate limits. We want to assure you that we are actively listening and taking your comments seriously. Our team is carefully reviewing your responses to ensure that we thoroughly address your questions and concerns.
Our goal with these changes is to create a fair, reliable, and scalable platform for everyone in the ecosystem. We recognize that updates to rate limits can raise important questions, and we are committed to working closely with our partners to ensure a smooth transition. You can expect thoughtful, timely responses from us as we continue this conversation together.
Link to the Quick Reference Guide: New points-based API rate limiting and tiered quotas for Jira & Confluence Cloud