Hit a wall with Rest API pagination

Hi Retool support & users,

Have been using Retool successfully over the past few months with postgres integration, love all the features however once its come to utilizing API's I've hit a brick wall with pagination.

I've tried the following solutions:
[Getting all results from a page-based pagination on API](https://Getting all results from a paged-based pagination on API)
http://community.retool.com/t/how-to-pull-a-all-data-from-a-paged-rest-api/7729[Returning all results for a cursor-based paginated API](Returning all results for a cursor-based paginated API)

I have a GET query for contacts from an API that works perfectly, except when it comes to trying to get more than one page from the API(as seen below) so I know that all the authentication is correct etc. The paging I believe is the only issue.
The API documentation outlines that paging works as follows:

Below is a screenshot of what I think is closest to succeeding. I have also tried using the Javascript queries in the above links and modified for my use but they were not returning any data.

Help on this issue would be much appreciated, I think I've come to the end of my attempts on and am just going in circles, it does feel like it is really close to working however!

Thanks in advance!

1 Like

Hey @tomrezoando!

The afterCursor property on your table can be super helpful here. We have some docs on cursor-based pagination here - the relevant part in this case I think is that whatever value you pass into the "Next cursor" field gets stored, and then at the moment you click to the next page the table updates its afterCursor property to be the next cursor, triggering your query, and pulling the next page.

I haven't tested with your API but from what I can see it looks like you have the "Next cursor" field set up correctly :+1: So you should be able to replace {{ exceptionTableABN.selectedPageIndex + 1 }} with {{ exceptionTableABN.afterCursor }}.

Can you let me know if that works better?

Hi @Kabirdas ,

Thanks for the response, it is much appreciated.

As per your instructions I have replaced {{ exceptionTableABN.selectedPageIndex + 1 }} with {{ exceptionTableABN.afterCursor }} and I can see what you mean. Once I get past the 50 records that the API allows in the first page (ie page 10 in my table, 5 records per table page) it will rerun the query. I do not have the next page set up in the table pagination settings either by the looks of things as it just grabs the same 50 records for pages 11-20.

The main issue that will arise I believe is that I am trying to get access to around 500-700 records in this query. Ideally I would like to have one query bring them all in so I can use a search function to narrow it down a little more if desired. Would you have any advice on how to get the query to bring in all records instead of just the 50?

Updated SS:


@tomrezoando this is a little tricky - it might be that your API is pulling in 50 results per page but that your table can only display the first 5. Can you control the page size of your query?

It also sounds like you might need another value to check whether there is a next page. This can vary greatly depending on the API though, can you share either an example response or some documentation for your API?

This is a small example of the response that I get from the API. It consists of 50 records in the format shown.

How would I go about checking whether or not there is another page?

:thinking: the array of contacts all that is return or are there any other fields on getContacts.data? (The state tab of debug tools can be particularly useful here as well)

If it's just the array you might try something like {{ getContacts.data.length === 50}} in the "Has next page" field. This assumes that the last page will return <50 records. It's a bit imperfect though because if you have some multiple of 50 records you need to be able to fetch a blank page as the last page.

I'm a little worried since it seems like requesting a page that doesn't exist just returns the last page - can you confirm whether or not that's the case?

Again, ideally, the API would have another property besides the records that indicates whether or not there's another page.