## 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.