Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Cost-based rate limit prevents enterprise IAM bulk provisioning — need guidance

Satyanarayana
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
June 4, 2026

We are using the Jira Cloud Bulk Issue Create API (/rest/api/2/issue/bulk) for enterprise IAM provisioning and are hitting the cost-based rate limit.

Our observed behavior:

  • Each ticket via bulk API costs ~150 units
  • 300,000 unit/hour limit = max ~2,000 tickets/hour
  • We need to provision 100,000 users = ~50 hours

Confirmed from 429 response headers:

Ratelimit-Reason:    jira-cost-based
X-Ratelimit-Limit:   300000
X-Ratelimit-Remaining: 0
X-Ratelimit-Reset:   2026-06-05T06:00Z

Questions:

  1. Why does each ticket cost ~150 units in a bulk request vs 1 unit for a GET?
  2. Is there a way to reduce the cost per ticket (e.g., fewer fields, no indexing)?
  3. Can the limit be increased for enterprise provisioning accounts?
  4. Is there a provisioning-specific API better suited for bulk user onboarding at scale?

2 answers

1 vote
Tomislav Tobijas
Community Champion
June 5, 2026

While a GET request is a simple read operation and it costs 1 unit, POST requests to create a work item are significantly more expensive as it triggers a chain of backend processes. 🔃

To reduce this a bit, you could try:

  • Minimize fields: like, only include mandatory ones in the request.
  • You could also try to optimize custom fields - this is a lot of work, but if fields do have "Global" context they also tend to get processed in these kinds of actions so indexing takes longer. This is fairly tricky, especially if you have Enterprise site, so I wouldn't chase this one much.
  • Disable Notifications: Use the ?skipNotifications=true parameter to prevent the system from generating and sending emails for every new user provisioned.
    👆 I've found this, never used it though, but might be worth a shot.

Can you maybe share the requirement here? How's IAM connected with bulk creation of issues/work items, and why do you need to create so many work items at once?

Cheers,
Tobi

1 vote
C_Faysal _CFcon_
Community Champion
June 5, 2026

Hi @Satyanarayana  


Worth separating two things up front, because provisioning user accounts and creating issues are different APIs with different limits.

A few details in the report don't line up with Atlassian's documented model, so I'd start there:

  • Ratelimit-Reason: jira-cost-based isn't a documented value. The documented reasons are jira-quota-global-based, jira-quota-tenant-based (hourly points quota), jira-burst-based (per-second burst), and jira-per-issue-on-write.
  • A fixed "~150 units per ticket" doesn't match the cost model. Per the docs, a write is charged only the base cost with no per-object points, and the published catalog puts an Issue at 1 point. A bulk create is cheap on the points pool, not 150.
  • Which regime applies depends on your auth. The points model covers Forge, Connect, and OAuth 2.0 (3LO) apps. API-token traffic isn't on the points model and stays governed by the per-second burst limits. If your IAM tool authenticates with an API token, burst is what you're hitting, not an hourly points budget.

So for creating 100k issues, design around the per-second burst limit (enforced per tenant and per endpoint), not a per-ticket cost:

  • POST /issue/bulk accepts up to 50 issues per request; more than 50 returns a 400. Send 50 per call instead of looping single creates.
  • Pace requests to stay under the per-second burst for that endpoint. On a 429, wait out Retry-After and back off exponentially with jitter, since reissuing early just resets the timer.
  • A higher per-tenant quota isn't self-service. The default is a shared global pool (65,000 pts/hr); a per-tenant pool is assigned only after an Atlassian review for sustained high usage. For a one-time onboarding it's usually simpler to run a paced background job than to chase a quota change.

If what you actually need is the user accounts rather than issues, that's a different API: the org-level User Provisioning (SCIM) API, which needs Atlassian Guard Standard and an org admin. You drive it from your identity provider (Okta, Entra, and similar), or call the provisioning API directly if your IdP isn't supported. issue/bulk doesn't create accounts.

Sources:

Rate limiting (reason values, points model, pool FAQ): 
https://developer.atlassian.com/cloud/jira/platform/rate-limiting/  

Bulk create, "Creates upto 50 issues" (current v3 API reference): 
https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-bulk-post  

Understand user provisioning (SCIM, Guard requirement): 
https://support.atlassian.com/provisioning-users/docs/understand-user-provisioning/ 

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events