POST /object/aql endpoint doesn't support pagination - unable to retrieve more than 25 objects

JSM Development
1

## Summary

The official POST /object/aql endpoint (replacement for deprecated GET /aql/objects) doesn’t support pagination parameters, making it impossible to retrieve more than 25 objects when a workspace contains hundreds or thousands of objects.

## Current Behavior

- POST /object/aql accepts only `qlQuery` in request body (per OpenAPI spec)

- API always returns exactly 25 results regardless of query

- No pagination parameters available (`page`, `resultsPerPage`, `startAt`, etc.)

- Response includes `isLast: false` when more results exist, but no way to fetch them

- Totalcount endpoint (/object/aql/totalcount) correctly reports total count (e.g., 1,116 objects)

## Expected Behavior

POST /object/aql should support pagination parameters to allow retrieving all matching objects, similar to the deprecated GET /aql/objects endpoint.

## Impact

- Workspaces with >25 objects of a given type cannot be fully queried via the official API

- Forces developers to use deprecated GET /aql/objects (scheduled for removal Sept 2024, still working Jan 2026)

- No migration path available when deprecated endpoint is removed

- Affects production systems relying on complete object retrieval

## Reproduction Steps

1. Create workspace with 100+ objects of same type (e.g., Application objects)

2. Use POST /object/aql/totalcount to verify total count (returns 1,116 in our case)

3. POST to /object/aql with query `{“qlQuery”: “objectType = Application”}`

4. Observe: response contains only 25 results despite totalCount showing 1,116

5. Note response shows `isLast: false` but provides no way to fetch remaining results

6. Attempt to add pagination params to request body - no effect, still returns 25 results

7. Compare with deprecated GET /aql/objects?qlQuery=objectType=Application&page=1&resultPerPage=100

8. Observe: GET endpoint correctly returns 100 results and supports pagination to retrieve all 1,116 objects

## Workarounds Attempted (All Failed)

1. **Multiple orderings** (Name ASC/DESC, Created ASC/DESC, Updated ASC/DESC) - yields ~150 unique results maximum, still missing 85% of data

2. **Alphabetic filtering** with LIKE operator - doesn’t work reliably with AQL

3. **startAt-style iteration** - no parameter available in POST endpoint

4. **Alternative endpoints** (/object/navlist/aql, /objectschema/{id}/objects) - return 404 errors

## Current Solution

Using deprecated GET /aql/objects endpoint which has proper pagination support but is officially scheduled for removal.

## Request

Please add pagination support to POST /object/aql endpoint. Suggested approaches:

1. Accept `page` and `resultsPerPage` in request body (matching GET endpoint behavior), OR

2. Implement cursor-based pagination with next/previous tokens in response, OR

3. Clarify documentation if there’s an alternative official API for retrieving large result sets

Without pagination support, the POST endpoint is not a viable replacement for the deprecated GET endpoint.

## Environment Details

- API Base URL: https://api.atlassian.com/jsm/assets/workspace/{workspaceId}/v1

- API Version: v1

- Workspace ID: 5cee96d4-e960-4188-91b8-f6ce02d7b73f

- Object Type: Application (objectTypeId: 91)

- Schema ID: 10

- Total Objects (via totalcount): 1,116

- Objects Retrieved via POST /object/aql: 25 (2.2% of total)

- Objects Retrieved via GET /aql/objects: 1,116 (100% with pagination)

- Date Tested: January 2026

## Additional Context

The deprecated GET endpoint was scheduled for removal on September 18, 2024, but remains functional as of January 2026, likely because the replacement POST endpoint lacks critical pagination functionality. This appears to be a blocking issue for the deprecation timeline.

2

I am running into this exact issue. Has anyone found a solution?

3

Have you tried specifying startAt? It works for me.

4

@rcsr could you please let me know exactly are you calling to get it to work? I try specifying the startAt value even at a higher number (e.g., 25) and the response I get back always has a startAt value of 0

5

It’s been a while and I don’t have an instance to test against but this is the what I used:

POST

https://api.atlassian.com/ex/jira/{{cloudId}}/jsm/assets/workspace/{{workspaceId}}/v1/object/aql?startAt=0&maxResults=100&includeAttributes=true

{
  "qlQuery": "..."
}

One other thing to note - setting maxResults > 1000 is currently buggy.

6

Thank you so much, that managed to work for me.

For anyone else that is experiencing this issue, before I was passing the startAt and maxResults values in the params which did not work.

In my case, pagination only started working once startAt and maxResults were passed as query string parameters on the endpoint URL that rcsr posted above.

One other thing I noticed is that the pagination metadata appeared inconsistent. On the first page the API returned:

{
  "startAt": 0,
  "maxResults": 100,
  "total": 120,
  "hasMoreResults": false,
  "isLast": false
}

So would not rely on the hasMoreResults as it seems to be unreliable.

Thanks again for the assist @rcsr :slight_smile: