Project Summary Publish: April 14, 2026 Discuss: April 28, 2026 Resolve: May 25, 2026 Problem Context Forge apps are subject to both Forge platform and Atlassian app limits, which are in place to ensure fair usage and reliability REST API calls from Forge apps to Atlassian apps (such…

This proposal won’t work well for our apps, and I hope it’s materially changed before being put into effect. The current per-user scaling points never quite made sense to me, but the number of users in an instance is a good proxy for the amount of content in the installation. Our app, and my guess i…

Hi @kashev , I’m not quite sure I understand your feedback. You say that per-user scaling points don’t make sense for you, but in this proposal we are removing the per-user scaling limits that exist today. The proposed rate limits will be greatly simplified and be only keyed by installation. Cou…

Rate limit scoped per tenant = structural isolation to prevent the noisy neighbour problem. Rate limit scaled per user = quota calculation that matches expected usage demand (and acts as a ~decent proxy for tenant content scale). Which means the formula should look something like: per-tenant quot…

Like @kashev and @nathanwaters said (I think), the number of licensed users should definitely affect the RPM limit. It doesn’t seem to make a lot of sense to apply the same limits for example to 5 and 50K user instances. Essentially repeating @nathanwaters formula: per-tenant quota (RPM) = base …

Thanks @nathanwaters and @jens for the feedback. At the time of invocation, we don’t have data on the total number of users on a tenant, so we aren’t able to apply that formula directly. Additionally, maintaining a uniform rate limit helps us to ensure the stability of our platform. However, we can…

That data gap needs to be fixed first then. A single tenant/install can have up to 100,000 users on Jira and 150,000 users on Confluence. How would a rate limiting model work that is not tied to that user count variable? REST API rate limit tier 1 global pool opens the entire marketplace to DoS a…

I want to raise a security concern with removing per-user limits. The current per-user cap (1.2k RPM) acts as a blast radius limiter – a single compromised account or malicious user cannot exhaust the entire installation quota and deny service to everyone else in the tenant. Removing it creates an …

@LilyYang – Thank you for this RFC. Like the other responders, I am confused by the idea of implementing installation-level limits that are insensitive to the number of users in an installation…especially given that the RFC is scoped to user-initiated events. A snippet from the problem statement: …

process to assign a higher limit to tenants with a large number of users on a per-needs basis As in prior comments, having to consider “per-needs” issues and requesting manual allocations would add additional complexity to a process that should ideally deal with all of this automatically. At th…

[image] LilyYang: How else we can be providing support in the period leading up to this change Two things are enormously important for helping us deal with rate limits, both before changes and in general: ALWAYS return the rate limit properties in a header, not just when a request is rate l…

RFC 130: Upcoming changes to invocation rate limits

General Request for Comments (RFC)

nathanwaters April 17, 2026, 4:48am 19

Hopefully not. The new API rate limit model did AND opened a new DoS attack surface.

1 Like