# Jira Cloud REST API v3 /search/jql: Slower Fetching with nextPageToken & No totalIssues – Any Workarounds?

**URL:** <https://community.developer.atlassian.com/t/jira-cloud-rest-api-v3-search-jql-slower-fetching-with-nextpagetoken-no-totalissues-any-workarounds/90176>\
**Category:** Jira Cloud\
**Tags:** jira-cloud, rest-api, atlassian-connect\
**Created:** [March 13, 2025, 4:08am UTC](https://community.developer.atlassian.com/t/jira-cloud-rest-api-v3-search-jql-slower-fetching-with-nextpagetoken-no-totalissues-any-workarounds/90176 "2025-03-13T04:08:05Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![longdo](https://avatars.discourse-cdn.com/v4/letter/l/ba9def/32.png) [@longdo](https://community.developer.atlassian.com/u/longdo)\
**Post date:** [March 13, 2025, 4:08am UTC](https://community.developer.atlassian.com/t/jira-cloud-rest-api-v3-search-jql-slower-fetching-with-nextpagetoken-no-totalissues-any-workarounds/90176/1 "2025-03-13T04:08:05Z")

</div>

Hi everyone,

I’ve been working with the **Jira Cloud REST API v3** , specifically the `/rest/api/3/search/jql` endpoint, and I’ve noticed some challenges with the new pagination approach using `nextPageToken`. I wanted to check if others have encountered similar issues and if there are any recommended workarounds.

1. `nextPageToken` Slows Down Fetching

Previously, using `startAt` and `maxResults`, we could paginate through results efficiently, even making parallel requests when needed. With `nextPageToken`, however, fetching issues has become noticeably slower because:

- We **must wait for one page to complete** before fetching the next, preventing parallel requests.
- This significantly **increases the total fetch time** for large datasets.
- The lack of control over pagination makes handling large result sets more cumbersome.

1. No `totalIssues` Field in the Response

In the past, API responses included a `total` field, which allowed us to determine the total number of matching issues immediately. Now, this information is missing, meaning:

- We need to make **an extra API call** just to retrieve the total count.
- This adds complexity to pagination and limits, requiring additional handling on our end.

I understand that `nextPageToken` might be aimed at improving API efficiency, but in practice, it has made fetching issues slower and more complicated.  
Is there an **official workaround** to handle pagination more efficiently?

[https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-search/#api-rest-api-3-search-post](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-search/#api-rest-api-3-search-post)

Thanks in advance for any insights.

---

<div class="post-metadata">

**Author:** ![glewandowski](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/glewandowski/32/51699_2.png) [@glewandowski](https://community.developer.atlassian.com/u/glewandowski)\
**Post date:** [March 31, 2025, 8:02am UTC](https://community.developer.atlassian.com/t/jira-cloud-rest-api-v3-search-jql-slower-fetching-with-nextpagetoken-no-totalissues-any-workarounds/90176/2 "2025-03-31T08:02:19Z")

</div>

Hey @longdo,

Thanks for raising this question. The problem with parallel calls is a common piece of feedback we’ve received. I wrote an article that explains how to avoid this issue. The entire solution becomes more complicated, but our tests show it yields the best performance results. You can read more about the solution [here](https://community.atlassian.com/forums/Jira-articles/Avoiding-Pitfalls-A-Guide-to-Smooth-Migration-to-Enhanced-JQL/ba-p/2985433).