RFC-127: Jira Software Cloud API Changes: Improving Scalability for Software Space Issue results

[GihanFernando]

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

Project Summary

Atlassian proposes to introduce new Jira Software Cloud public API endpoints for APIs returning paginated issue data. These changes will enable the use of a new issue search architecture to address increased scalability and reliability issues, and allow Jira Software capabilities to scale and perform for our growing customer and vendor needs.

The proposed API changes introduce a new pagination API pattern—continuation token (cursor/scrolling) pagination via nextPageToken. These changes will be consistent with a previous change to Jira Platform REST endpoints for JQL Search and Expression Evaluation (see changelog and RFC), aligning how issue data is paginated across Jira REST APIs.

The new endpoints will be eventually consistent by default, following the model established in the recent JQL search API changes. Atlassian is also seeking feedback from partners on whether there is a need to support higher consistency guarantee options for integrations that require immediate visibility of recent changes.

We believe these API pattern and consistency model changes deserve your attention.

Publish: Feb 05, 2026
Discussion Close: Feb 19, 2026
Resolve: Feb 26, 2026

Problem

Jira Software Spaces utilise JQL searches to power many capabilities, including Company Managed Space board filters, quick filters, swimlane queries, and JQL filter expressions in REST API requests. As a result, Jira Software Space APIs that return issue data face the same scalability and reliability challenges previously discussed in RFC-61: Evolving Search Capabilities: Addressing Scalability with a New, Enhanced Search API regarding Jira Platform REST endpoints for Search and Expression Evaluation, leading to the introduction of a new enhanced JQL Search REST API (Atlassian developer changelog).

Today, these Jira Software Space APIs use offset-based pagination, which allows random access to paginated results by specifying an offset (e.g., startAt). To provide random access, the system must often process all preceding results to return a specific page. As customer data volumes in Jira Spaces and query complexity have grown, this approach has led to increased response times, higher resource consumption, and a greater risk of timeouts or errors for customers using these APIs.

Additionally, these APIs return the total count of matching issues, which further impacts performance and reliability as mentioned in RFC-61. These patterns are not sustainable as Jira continues to scale to support larger and more complex customer use cases.

To address these challenges, we propose moving to a continuation token (cursor/scrolling) pagination model, as recently adopted in the Jira Platform REST APIs for Search and Expression Evaluation (see Atlassian developer changelog). This model enables efficient, sequential access to large result sets, improves scalability and reliability, and aligns Jira Software APIs with JQL Search REST APIs.

Proposed Solution

Atlassian will introduce new API paths for the affected Jira Software public APIs, implementing continuation token (cursor/scrolling) pagination and deprecating the existing offset-based endpoints.

This approach closely follows the migration pattern used for the JQL search API (see changelog), ensuring consistency across APIs and minimising migration complexity for partners.

Affected Endpoints

The following Jira Software public APIs will be replaced with new endpoints:

• GET /rest/agile/1.0/board/{boardId}/issue

• GET /rest/agile/1.0/board/{boardId}/backlog

• GET /rest/agile/1.0/sprint/{sprintId}/issue

• GET /rest/agile/1.0/epic/none/issue

• GET /rest/agile/1.0/epic/{epicIdOrKey}/issue

• GET /rest/agile/1.0/board/{boardId}/sprint/{sprintId}/issue

• GET /rest/agile/1.0/board/{boardId}/epic/none/issue

• GET /rest/agile/1.0/board/{boardId}/epic/{epicId}/issue

New endpoints will be introduced under a new API path (final path pending), with the following key changes (compared to existing APIs):

Query Parameters

• Removed: startAt : Integer

• Added: nextPageToken : String - Continuation token for scrolling pagination

Note: maxResults : Integer is retained as the query parameter for specifying the page size.

Response Fields

• Added:

  • nextPageToken : String - The token to use for fetching the next page (or null if there is no next page)

  • isLast : Boolean - Indicating if this is the last page

• Removed:

  • total: For consistency with the JQL Search API, total count will be removed

Eventual Consistency

The new endpoints will be eventually consistent by default, in line with the recent changes to the REST APIs for JQL Search and Expression Evaluation. This means that recent changes to issues may not be immediately reflected in issue results returned by these APIs. This trade-off is necessary to achieve the scalability and performance improvements required for large-scale Jira instances. Please see below if you have a need for higher consistency guarantees.

Deprecation and Transition

• The existing endpoints will be marked as deprecated once the new APIs are available

• We are targeting a deprecation period of 6 months, after which the old endpoints would be removed.

Alignment with JQL Enhanced Search API

• The new endpoints’ pagination and eventual consistency model are designed to be consistent with the recent JQL search API changes.

• The continuation token pagination will behave consistently with the pagination in the JQL enhanced search API (The Jira Cloud platform REST API), to reduce cognitive load for developers working across Jira APIs.

Other considered changes

There are other changes we are considering for these APIs that we would appreciate your input on.

We recognize that some integrations may require higher consistency guarantees. In the JQL enhanced search API, this is addressed via the optional reconcileIssues parameter, which allows you to specify issue IDs to be reconciled for higher consistency in the response (see detailed explanation here). If we supported this parameter in the new Jira Software Space endpoints, it would behave in the same way as in the JQL search API.

We are also considering the following changes to the issue data returned from the affected endpoints, again to be consistent with the JQL enhanced search API:

• When the comment field is requested (including if requested by default), we will return a maximum of 20 comments per issue - to fetch more comments for an issue, use the Get comments API.

• When the changelog expand parameter is provided, we will return a maximum of 20 changelogs per issue - To fetch more changelogs for an issue, use the Get changelogs API

Timeline

We’re sharing a proposed timeline for these changes:

• Feb 05, 2026 → We’re publishing this RFC seeking your feedback and making new experimental endpoints publicly available

• Feb 19, 2026 → We’ll close this RFC for discussion

• Feb 26, 2026 → We’ll resolve this RFC and share any planned updates with you based on your feedback

• End of March 2026 (tentative) → Depending on feedback, we’re targeting this date to launch the new APIs, and mark the existing APIs as deprecated. Rework may push this date out.

• After deprecation notice ends → Deprecated APIs are removed from service.

Asks

While we would appreciate any reactions you have to this RFC (even if it’s simply giving it a supportive “Agree, no serious flaws”), we’re especially interested in learning more about:

• Are there any use cases or workflows that may be negatively impacted by the proposed changes?

• What challenges do you foresee in migrating to the new APIs?

• Is there a need for optional higher consistency guarantees? Would support for a reconcileIssues parameter, as implemented in the JQL enhanced search API, meet your needs for higher consistency guarantees?

• Are there any challenges you foresee associated with the further considered changes regarding issue comment and changelog data?

• Are there any inconsistencies or gaps between these changes and the recent JQL search API migration that we should address?

We look forward to your feedback to ensure a smooth and successful migration for all partners.

[matthias]

Because this RFC is about making more endpoints eventual consistent, I think it’s an absolute requirement to have one API call return consistent data. In most cases, I don’t care if I get some data a bit sooner or later, but I want to rely on that the data I get is consistent in itself.

I’ve described a negative example in the comment of the issue here (don’t get confused by the irritating title and vague issue description).

[hitsthings]

In my opinion, Jira’s eventual consistency is a travesty. I have issues that are not ready even after 2 minutes, when created in fresh prpjects. So making more things eventually consistent is an absolutely terrible idea to me.

reconcileIssues is not helpful. It doesn’t enforce consistency but instead just makes that single request include the correct issues. This means it does not help two separate systems stay consistent. For example in func tests I might create an issue. My app then is expected to show the issue. For reconcileIssues to be helpful, my func tests need to tell my app which issues to use in the reconcileIssues param which would severely complicate app code and func test code. It’s not a practical solution. Instead I poll until the issue is available. This takes over 2 minutes sometimes.

If you are going to make anything eventually consistent, please have performance alerts set up. No issue should take more than about 5s to become available. Make this a pagerduty alert when it happens.

As far as cursors, that makes sense to me. I do take advantage of the counts in some places, but I believe the performance gain of not grabbing all results is probably worth it. Offering a count as a separate request could be useful for paging purposes.

[AndreasEbert]

I can also see the performance improvement by these changes.

… will return a maximum of 20 changelogs per issue … we will return a maximum of 20 comments per issue …

Probably stating the obvious, but just to be sure: The returned comments/changelogs should be the newest 20, not the oldest 20. And they should be ordered from newest to oldest, as is already the case now.

[ryan.brown]

I generally support the direction of this RFC and the scalability improvements being proposed. Improving performance and reliability at scale is clearly necessary and the move toward eventual consistency for high-volume operations makes sense.

My main concern is around API consistency and the cognitive load this creates for app developers. This RFC only applies to 5 of the board REST API resources, leaving ~15 others on the existing v1 APIs that behave differently and are not eventually consistent. From an app engineering perspective, this split significantly increases complexity: developers now need to reason about which board endpoints are strongly consistent vs eventually consistent, despite them conceptually belonging to the same API surface.

To reduce this inconsistency and ensure more predictable results from the Board APIs as a whole, I’d strongly encourage Atlassian to consider including the following endpoints in scope for these changes:

• GET /rest/agile/1.0/board

• GET /rest/agile/1.0/board/{boardId}

• GET /rest/agile/1.0/board/{boardId}/configuration

• GET /rest/agile/1.0/board/{boardId}/epic

• GET /rest/agile/1.0/board/{boardId}/features

• GET /rest/agile/1.0/board/{boardId}/project

• GET /rest/agile/1.0/board/{boardId}/project/full

• GET /rest/agile/1.0/board/{boardId}/properties

• GET /rest/agile/1.0/board/{boardId}/properties/{propertyKey}

• GET /rest/agile/1.0/board/{boardId}/quickfilter

• GET /rest/agile/1.0/board/{boardId}/quickfilter/{quickFilterId}

• GET /rest/agile/1.0/board/{boardId}/reports

• GET /rest/agile/1.0/board/{boardId}/sprint

• GET /rest/agile/1.0/board/{boardId}/version

• GET /rest/agile/1.0/board/filter/{filterId}

Aligning these resources under the same consistency and scalability model would make the Board APIs easier to reason about, safer to consume, and more predictable for both existing and future apps.

[TurnerIpock]

I think somewhat to @ryan.brown’s comment, as you are changing the underlying way that data is being delivered, you should increment the API number to V2 and completely separate out the API’s that you see as being eventually consistent vs. the current model, similar to the way things are operating with ADF. Now developers will easily know what is going on in the background, and you can start to logically deprecate API versions, not just individual endpoints. Versions can have wholistic changelogs attached to them, and you can batch all this stuff into a single change vs. drips everywhere.

The only issue I see overall with the nextPageToken model is twofold, it reduces the ability for users to be able to skip over pages, for many implementations where this data is shown, it will be implemented in a ‘infinite scrolling’ way. This means all that data will be cached in the browsers window.

One of the biggest issues that I have been having recently is the required memory footprint of Jira and Confluence pages. By far, Jira and Confluence tabs (appear) take up more memory than most other sites I have open (can be 20-40 tabs at any one time). With the ‘new’ Jira Filter screen, it initially loads to a 247 MB heap size; after scrolling for just a few seconds, it can jump up to 700+MB heap and will calm back down to around 302 MB. So, while you may be technically solving a backend performance issue, depending on how things are implemented in the front end, you may be just pushing the performance issue out somewhere else, as I am regularly having to hunt down Jira and Confluence tabs to close out to fix memory related issues on my workstation.

[GihanFernando]

Hi @matthias, thanks for your response. I understand your concern from reading that JAC ticket - thanks for sharing. Please monitor updates there, as it will be best evaluated on that ticket.

[GihanFernando]

Thanks for the feedback @hitsthings. With regards to the experience with performance, the delay in eventual consistency is dependent on various factors. The majority of modifications are typically visible within seconds. However, operations that impact numerous issues, such as lexorank rebalancing or bulk editing, may require more time to complete.

If you believe your case reflects a simple change that should appear sooner, contact support. We will investigate that specific case further.

[GihanFernando]

Hi @ryan.brown, thanks for your feedback. I understand the developer need to distinguish between strong and eventual consistency. For context, the proposed changes target endpoints that search and return issue data. These changes aim to resolve scaling and performance issues related to returning issue data.

From your list, I don’t see them returning issues, except this one which I’m now interested in:

• GET /rest/agile/1.0/board/{boardId}/epic

This endpoint may also be relevant to this RFC but is currently missing from the affected list. I will investigate further.

[GihanFernando]

Hi @TurnerIpock, thanks for your response! Incrementing the API version number was also considered, this proposal includes introducing a new endpoint as it models changes proposed by a similar RFC. We do see the additional benefit to reducing cognitive load on developers (by opting for a API version increment instead) so it will be considered.

That’s correct, with the introduction of nextPageToken it removes the ability for random page access. With the current offset based approach, the system would process the preceding pages until it reached the desired page of data. The performance of this approach can vary - depending on the customer data. The motivation behind proposed changes in this RFC are to allow Jira Software capabilities to scale and perform for growing customer and vendor needs.

With regards to a memory footprint. I think you’re right in that it would depend on the context of how things are implemented in the front end and thus something to consider from a consumer perspective.

[GihanFernando]

Hey @AndreasEbert, thanks for the feedback!

Yes - you’re correct, the changelogs returned via the expand parameter would return the most recent ones, sorted by date, starting from the most recent.

However, with the comments requested via fields, I noticed the newest 20 would be returned, however their order wasn’t what I expected - they were oldest to newest.

[LeonRothYasoon]

We are seeing extreme degradation in the endpoints mentioned in this RFC e.g. rest/agile/1.0/board/{boardId}/issue?maxResults=1 is taking north of 30 seconds currently. Is this related to the RFC or any changes connected to this RFC?