All list endpoints across AscendAPI products use cursor-based pagination. This page explains how it works, how to navigate through results, and how it compares to traditional offset-based pagination.
How It Works
Each list response returns a data array alongside a meta object that contains everything you need to navigate to the next or previous page.
{
"success": true,
"meta": {
"total": 2289,
"hasNextPage": true,
"hasPreviousPage": false,
"nextCursor": "edb_T5uXtLj",
"previousCursor": null
},
"data": [...
]
}
| Field | Type | Description |
|---|
total | number | Total number of exercises matching the current filters |
hasNextPage | boolean | Whether more results exist after the current page |
hasPreviousPage | boolean | Whether results exist before the current page |
nextCursor | string | Exercise ID to pass as after for the next page |
previousCursor | string | Exercise ID to pass as before for the previous page |
Navigating Pages
First Request
No cursor is needed on the first request. Use the limit parameter to control how many results are returned per page.
curl -X GET "https://edb-with-gifs-and-images-by-ascendapi.p.rapidapi.com/api/v1/exercises?limit=10" \
-H "X-RapidAPI-Key: YOUR_API_KEY" \
-H "X-RapidAPI-Host: edb-with-gifs-and-images-by-ascendapi.p.rapidapi.com"
Next Page
Pass the nextCursor value from the previous response as the after parameter.
curl -X GET "https://edb-with-gifs-and-images-by-ascendapi.p.rapidapi.com/api/v1/exercises?limit=10&after=edb_T5uXtLj" \
-H "X-RapidAPI-Key: YOUR_API_KEY" \
-H "X-RapidAPI-Host: edb-with-gifs-and-images-by-ascendapi.p.rapidapi.com"
Previous Page
Pass the previousCursor value as the before parameter to go back.
curl -X GET "https://edb-with-gifs-and-images-by-ascendapi.p.rapidapi.com/api/v1/exercises?limit=10&before=edb_mbpKFKd" \
-H "X-RapidAPI-Key: YOUR_API_KEY" \
-H "X-RapidAPI-Host: edb-with-gifs-and-images-by-ascendapi.p.rapidapi.com"
With Filters
Pagination works alongside all available filters. Pass any combination of query parameters together with the cursor.
curl -X GET "https://edb-with-gifs-and-images-by-ascendapi.p.rapidapi.com/api/v1/exercises?limit=10&after=edb_T5uXtLj&bodyParts=Chest&equipments=Barbell,Dumbbell&difficulty=intermediate&exerciseTypes=strength" \
-H "X-RapidAPI-Key: YOUR_API_KEY" \
-H "X-RapidAPI-Host: edb-with-gifs-and-images-by-ascendapi.p.rapidapi.com"
Stop paginating when hasNextPage is false. No results exist beyond that point.
AscendAPI uses cursor-based pagination instead of the traditional page/offset approach. The table below explains the key differences.
| Cursor-Based | Offset-Based |
|---|
| Mechanism | Uses an exercise ID as a stable pointer | Uses page and limit numbers to skip rows |
| Performance | Consistent at any depth | Degrades on large datasets due to row scanning |
| Stability | Results stay consistent as data changes | New inserts or deletes can shift page results mid-pagination |
| Random access | Sequential only | Can jump to any page number |
| Best suited for | Feeds, infinite scroll, large datasets | Small datasets, numbered page UIs |
Offset pagination works by scanning and discarding rows before returning results. On large datasets, requesting a deep page means the database scans thousands of rows before serving your response. Cursor-based pagination skips this entirely by using a record ID as a direct reference point, making every page request equally fast regardless of dataset size.
Plan-Based Record Limits
On certain AscendAPI products, your plan determines how many records you can access in total, not just per page. This affects pagination directly as total in the meta object will reflect your plan limit rather than the full dataset size.
For example, if your plan includes access to 1,000 records, pagination will stop at 1,000 results regardless of the full dataset size.
To check the limits included in your plan, refer to the features listed on the product page.
For any queries reach out at hello@ascendapi.com.