Not that pagination and "start-at" mechanisms are inherently broken.... Assume we have items sequentially numbered 1 thru 5000... Pagination is set to 25 items..
So expectation:
   first call: 1 thru 25
   second call 26 thru 50

BUT if the collection changes between the calls 
Say #3 is deleted after the first call.. Then "skipping 25" would result in 27 thru 51 being returned and #26 never beeng seen.

ATOMIC results require the use of some persistent (Atlassian server side)  snapshot to ensure that all of the (potentially hundereds of sequential reqests) all are related to the data as it exists at a single point in time.

This is a difficult limitation for our system, which is built on top of Jira systems. The given limitation and reasons are not acceptable. Please consider increasing the limits, or at the very least provide an offset parameter to the API so multiple calls can be a workaround. 

I am really sorry that I migrate from server to cloud. Now it's hard to return. This is not acceptable.

Jira has tons of basic cloud software issues that other cloud software are offering in the market. THIS IS REALLY VERY BAD APPROACH FROM JIRA

david.leal, k4el,

I understand your point and I agree it would be much more comfortable being able to export everything in a shot. On the other hand I have to agree with the developers that it is very difficult to determine the average amount of data each issue may contain and, since we have seen cases in the past of people literally DoSsing their instances by trying to retrieve way too many issues at the same time, they decided to set some kind of 'safe' limit.

For more details on this, see:

• https://ecosystem.atlassian.net/browse/DEVHELP-1027
• https://ecosystem.atlassian.net/browse/ADDON-230

Finally, there is actually an open Feature Request to have the limit increased that has been created more than one year ago but that got only one vote so far:

• JRACLOUD-67722

I have linked the feature request to this ticket so that maybe more people will be aware of it and will vote for it, giving it a chance to get back on the developers' table at some point in time.

Incorrect behavior attributed to an "optional" parameter is just making excuses. Policy that allows you to avoid fixing a product people have paid for is just an excuse with paper work.

@Dario Bonotto, I guess you understand my point people are very disappointed with this approach. I implemented a REST API solution for exporting 2.6K issues, and because of this 100 record limitation, it takes to me about 5 minutes to get all of them in excel. Using a CSV export option that also has a limit about 1000 (not 10K) it takes much less time, but in order to load the information into excel, I need to build a different logic for downloading the file, uploading, parsing the information and dealing with the fact that the excel columns are not consistent among files, because it create an additional column per Sprint (when the issue has been in more than one sprint) and by labels (when there is more than one). Therefore the CSV file format changes dynamically based on the information downloaded, without changing the columns to export.

Now I need to deal with the logic for getting more than 1K records using excel export (because of the performance) and the logic for using the REST API for a small amount of data.

Having a limit of 1K for both ways is at least more consistent, and also having a CSV file format that does not change dynamically based on the number of labels, components or Sprint like it happens now. It makes more difficult the logic for parsing the information. For example, using a String of elements delimited in the same column instead of adding dynamically a new column that is more difficult to handle. 

david.leal As mentioned in the status update on the top of the description, you can use pagination to get all the results.  A similar approach can be used to get more than 10000 result when exporting to CSV (or the old export to Excel).

I believe that no doctor will ever give you all your medical records in one single page (unless it is very little data) since there is a limited amount of text you can put on a page before it becomes unreadable. The same concept applies here.

For details see:

• The Jira Cloud platform REST API - Expansion, pagination, and ordering
• Export More than 1000 Issues to Excel from Issue Navigator in JIRA Cloud  

How Atlassian can put a restriction like this? it means we don't own our data in Jira. Imaging I am going to the doctor for requesting my medical records and I got the same answer: We can give you only the first two pages of your records but you can visit us every day and we will give you the next two pages until you get all your records. This is insane. We have a limitation for exporting into excel file and now this low limit for the REST-API.

Hi mike.loux,

As mentioned in the documentation the 'isLast' property is optional. This means that is not returned by all the endpoints.

E.g.
if I call the search endpoint indeed I don't get it:

{"expand":"schema,names","startAt":0,"maxResults":50,"total":7,"issues":.....

While if I call rest/agile/1.0/board/ID/sprint:

{"maxResults":50,"startAt":0,"isLast":true,"values".......

However, while checking the documentation I have seen that the example for the 'search' endpoint is wrong. I have opened a request to get the documentation fixed:

• JRACLOUD-70163

Cheers,
Dario