nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Satyanarayana_berh29

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:

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

Accepted answers

All comments

C.Faysal {CFcon}

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/

Tomislav Tobijas

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

Satyanarayana_berh29

Hi @C_Faysal _CFcon_,

Thank you for your response.

We are building an enterprise IAM (Identity Access Management) provisioning system. Whenever a user is granted access to an application, we create a Jira issue as a tracking and approval ticket. For large organizations with more than 100,000 users being onboarded, we may need to create 100,000+ tickets during a single provisioning run.

I would like to clarify the following points:

Does ?skipNotifications=true actually reduce the cost units per request, or does it only suppress email notifications without affecting the rate-limit cost?
Is there a way to determine the exact cost of a request through response headers (for example, something similar to X-RateLimit-Cost) so that we can measure the impact of any optimizations?
We are using API token authentication (Basic Auth). A community expert mentioned that API tokens are governed only by burst limits and not by cost-based limits. However, we are receiving HTTP 429 responses with RateLimit-Reason: jira-cost-based. Does Jira's cost-based rate limiting also apply to requests authenticated using API tokens?
Using the single issue creation API (POST /issue), we were able to create approximately 500,000 tickets over a 24-hour period without encountering any rate limits. However, when using the bulk issue creation API (POST /issue/bulk) with batches of 50 issues per request, we started receiving jira-cost-based rate limits after processing only about 1,500 tickets per hour.
Could you help us understand why the bulk API appears to consume significantly more cost per ticket than the single-issue creation API?

Thank you for your assistance.

Satyanarayana_berh29

@C_Faysal _CFcon_ ,We implemented ?skipNotifications=true on the bulk issue creation endpoint, and it appears to have helped. Previously, we were hitting rate limits after creating approximately 400 tickets per hour, whereas now we can create around 800 tickets before encountering the same limit. This suggests that the cost per ticket may have been reduced by roughly 50%.

Our current ticket payload is:

{
  "fields": {
    "project": { "key": "QA" },
    "issuetype": { "name": "Task" },
    "summary": "Account Creation for johndoe",
    "description": "Request Type: ADD\nApplication: TestApp\nName: johndoe\nEmail: john@company.com\nFirst Name: John\nAccount ID: ACC001\nBusiness Justification: Automated Request From Orsus",
    "components": [{ "id": "10042" }]
  }
}

We have a few additional questions:

Which fields in this payload contribute most significantly to Jira's cost-based rate limiting? For example, is the description field more expensive because of indexing or additional processing?
If we remove the description and components fields, is there any expected reduction in cost per ticket? If so, is there any guidance on the magnitude of that reduction?
Is there any way to determine the exact cost consumed by a request? For example, does Jira expose a response header such as X-RateLimit-Cost or any other metric that would allow us to measure request cost directly?
Since enabling skipNotifications=true appears to have doubled our throughput before rate limiting occurs, can you confirm whether this parameter actually reduces the cost units consumed by a request, or whether it simply suppresses email notifications and the observed improvement is due to another factor?

Any guidance on optimizing ticket creation throughput for large-scale provisioning workloads would be greatly appreciated.

Thank you.

C.Faysal {CFcon}

Hi @Satyanarayana,

Good follow-up, and thanks for sharing the actual numbers. The 400 to 800 jump is worth digging into, but I want to separate what the docs actually say from what the before/after sample can tell us, because they point in different directions here. Let me take your questions in an order that builds on itself.

First, the API-token vs cost-model question (your earlier point)

This one is foundational, so it goes first. The rate-limiting page has an explicit carve-out: "API token-based traffic is not affected by this change, and will continue to be governed by existing burst rate limits." If your script authenticates with an API token over Basic Auth, that sentence is the one to read closely, because it suggests the points/quota model may govern your traffic differently than it governs a Connect/Forge app. I'd stop short of saying tokens can never be cost-limited, the docs don't state that either way. The jira-cost-based reason value that's come up in community threads is not in the official rate-limiting documentation that I can find, so treat it as community-reported rather than documented. The cleanest way to know which world you're in is to read the RateLimit-Reason header on your own 429s (more on that below).

Second, skipNotifications on the bulk endpoint (the big one)

Here's where the docs and your observation pull apart, so I'll be precise about each side.

On the documentation side: skipNotifications is not a documented parameter on POST /rest/api/3/issue/bulk. In the current v3 OpenAPI spec, that endpoint (createIssues) declares an empty parameters list, so no query parameters at all, and the string skipNotifications doesn't appear anywhere in the v3 spec. The single-issue POST /rest/api/3/issue declares exactly one query param, updateHistory, which has nothing to do with notifications. So whatever your ?skipNotifications=true is doing, it isn't doing it via a documented v3 parameter. I want to be careful here: an empty parameter list proves the param is undocumented, not that the server ignores it. Older Jira REST surfaces have honored undocumented flags before, so the honest statement is "undocumented, effect-if-sent unspecified." Don't build a production pipeline on it.

On the cost side: the documented write-cost model gives no basis for a "50% cost per ticket" reduction. The page says "Each request starts with a base cost of 1 point, and additional points are added for each object involved. Write requests are charged only the base cost, with no additional points." And "All write operations cost 1 point regardless of object type." A create is 1 point whether notifications fire or not. There is no documented lever by which suppressing notifications lowers the point cost of a write. I'd avoid concluding that skipNotifications cuts cost units, because the docs don't support that claim.

So how do you reconcile a real 2x in throughput-before-429 with a cost model that says nothing changed? A few documented-limiter hypotheses are worth weighing, and I'd label all of them as hypotheses until your own headers confirm one:

- You may be hitting a different limiter than the points quota. Jira documents three: points quota (jira-quota-global-based / jira-quota-tenant-based), burst per-second (jira-burst-based), and per-issue-on-write (jira-per-issue-on-write). A change in throughput-before-429 can mean the wall moved between these, not that any single request got cheaper.
- Shared-pool variance. The points pool is shared and resets at the top of each UTC hour. Two runs at different times, with different burst-bucket state or background tenant load, can differ by a lot without any parameter mattering.
- A single before/after sample is easy to over-fit. One run at 400 and one at 800 is two data points. Time-of-day, concurrency, batch sizing, and retry behavior all move that number.

I'd resist locking in "skipNotifications doubled it" from one pairing. It might hold up, but the docs don't predict it, so it needs more than two runs to be a finding.

Third, per-field cost (description, components, trimming fields)

Same documented model answers this: field content is not a cost factor for writes. A create is base-cost-only, 1 point, "regardless of object type," and the cost scales with the count of objects created, not with how rich any field is. The batch example in the docs makes this concrete: 50 creates is "50 points consumed from the quota (50 issues x 1 point each)," with no term for payload size or field count. So removing the description or the components field has no documented effect on per-request cost. If you measure a throughput change after trimming fields, that magnitude is undocumented, treat it as something to verify on your tenant rather than a known ratio.

Fourth, a cost header (X-RateLimit-Cost)

There's no documented X-RateLimit-Cost header on the REST API. The documented set you can actually read on responses is RateLimit-Reason (which of the three limits you hit), Retry-After, and the X-RateLimit-* family including the reset/interval values. If you want an exact per-operation cost number, GraphQL returns one directly via extensions.cost on the response, and REST has no documented equivalent. Inferring REST cost by watching your remaining-quota deltas across calls is a workaround, not a documented header, so label it as inference if you go that route.

Fifth, bulk vs single per-ticket cost

Whether one bulk call of N issues costs less per ticket than N single calls is not documented as a ratio. The docs encourage bulk mainly to "reduce the number of HTTP calls," and they caution to "check the point cost for your specific use case and ensure batching actually reduces overall quota usage." So the win bulk gives you is fewer requests against the per-second burst bucket, not a documented per-ticket discount. If there's a per-ticket cost difference, it's undocumented, measure it, don't assume a number.

Putting it to work for large-scale provisioning

For a provisioning job at your scale, here's what I'd actually do:

1. Instrument before you optimize. Log RateLimit-Reason on every 429 and watch the X-RateLimit-* deltas across calls. That single header tells you whether you're hitting burst, per-issue-on-write, or the points quota, which is the thing that decides every other tuning choice. Right now you're tuning blind to which wall you're at.
2. Back off honestly. Honor Retry-After and the reset values, and use exponential backoff with jitter so parallel workers don't resynchronize into the next spike.
3. Respect the per-issue write windows (20 writes / 2s and 100 writes / 30s on a single issue) if your flow updates the same issue repeatedly. Creating many distinct issues won't trip that one, but post-create edits can.
4. Treat the per-tenant pool as an app-quota construct. It's documented for app traffic, and given the API-token carve-out above it may not govern a token-auth script the same way, so confirm with your own headers rather than assuming it applies.
5. Take the two real doc gaps to Atlassian. The jira-cost-based reason value on token traffic, and any actual point cost of the bulk endpoint, are genuinely not published. With reproducible evidence (your headers, your timings), those are good questions for Atlassian Developer Support, and the kind of thing they can answer authoritatively where the public docs go quiet.

Net: report the 2x as your observation, because it is one. Just don't pin it to a documented cost reduction, because the write model says a create is base-cost-only and skipNotifications isn't a recognized v3 parameter. Read your RateLimit-Reason headers and you'll likely find the real story is which limiter moved, not which request got cheaper.

Hope that helps untangle it.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud