1,000 Issues, One Call: Bulk Fetch Gets a 10× Boost

[#1]

We've raised the ceiling on the Jira Cloud POST/rest/api/{version}/issue/bulkfetch endpoint. Where a request could previously return 100 issues, eligible requests can now return up to 1,000 issues — a 10× increase in throughput per call.

For apps and integrations that pull large volumes of issue data, that means the same workload in a fraction of the requests. 

Why it matters

Fewer, larger calls translate directly into:

• Better performance — one round trip instead of ten. Large reports and syncs finish faster with less overhead.

• Lower cost — fewer requests to make, retry, and orchestrate on both sides of the wire.

• More headroom within rate limits — collapsing ten calls into one is ten times less pressure on your per-tenant rate limit budget, leaving room for the rest of your app's traffic.

How to qualify for the larger limit

By default you can request up to 100 issues in a single call. To return up to 1,000, a request must be shaped so it can be served efficiently — every one of the following must be true:

• The fields parameter explicitly names at least one field. A request with only exclusions is not eligible, and neither are the *all / *navigable wildcards or the default navigable field set — the number of resolved fields depends on the site's configuration.

• No more than 100 fields are explicitly included.

  • No list-type fields — such as attachment, comment, or worklog

• No heavy expand values — such as changelog, renderedFields, or transitions

Requests that don't meet all of these conditions continue to be limited to 100 issues. Adopting the pattern is simply a matter of scoping your fields list to what you actually consume.

Refer to the public documentation which will ensure you are up to date with any changes over time.

Before and after

The response shape is unchanged — you still get an issues array with per-issue errors, so partial success works exactly as before. If you request more than the applicable maximum (100, or 1,000 for large-batch eligible requests), the endpoint returns 400.

How we did this

Raising the limit wasn't just a matter of changing a number. It reflects our continued investment in Jira Cloud's performance and scale — from the cloud-native architecture and purpose-built platform services described in How We Unlocked Performance at Scale with Jira Platform to the caching, sharding, and resilient service patterns that make high-volume workloads more predictable.

Those investments create benefits across the platform, not just in headline latency or reliability improvements. By understanding and bounding the cost of different workloads, teams can safely unlock new capabilities — such as allowing eligible Bulk Fetch requests to return up to 1,000 issues per call while keeping response times and backend load in check.

The result is a virtuous cycle: continued work on performance and scale improves the experience for customers and creates room for more efficient APIs, lower infrastructure costs, and greater throughput. This 10× Bulk Fetch improvement is one example of how that platform investment turns into practical benefits for apps and integrations.

Proven in the wild

This isn't theoretical. Tempo Software, an early adopter, cut their calls to this endpoint by up to 85% after moving to the new pattern — with the biggest wins on their largest customer configurations. We're seeing the same story across other customer sites: a clear, sustained drop in Bulk Fetch traffic once the pattern is adopted.

Get started

Review your Bulk Fetch usage, trim your fields to what you actually consume, and batch in units of 1,000. See the Bulk Fetch API reference for full details.

[Suresh]

Hopefully Scriptrunner will adapt to this change and increase their limit

[Gary Spross]

Very nice! More efficient calls like this are always welcome.

[Sami Shaik]

Thanks @Keri Miriello , this is a real throughput win, and I would add one practitioner note for admins reading it: the most common bulkfetch call in the wild sends only issueIdsOrKeys and no fields, which means the default navigable set, which means it stays at 100. Nothing errors, nothing gets faster. So the first step is not "raise the batch size," it is "go and look at whether your integration names its fields at all." Two patterns that have worked for me on large syncs, both consistent with the rules above: keep the 1,000-key call for single-value fields and take comments and history through separate narrower calls (the bulk changelog endpoint handles 1,000 issues by up to 10 field IDs), and read the returned count and keep paging rather than assuming 1,000 came back, per Atlassian's own advice not to hard-code endpoint limits. @Suresh  point about ScriptRunner is the one to watch: apps that wrap this endpoint will each pick their own moment to adopt the new shape.