Why pagination?

A lot of the time, when you’re making calls to the Hike APIs, especially products and customers, there’ll be a lot of results to return. For that reason, we paginate the results to make sure responses are easier to handle.

Let’s say your initial call is asking for all the products in a Hike store; the result could be a massive response with thousands of products. That’s not a good place to start. Rather than that, we’ve built in a page_size limit on results where there is a chance of large data response. With this you can explicitly set the page_size parameter to ensure you can get as many results per page as you require.

Set the page_size parameter

For example, you might need to request all products in a Hike store, but you only want the 100 results at a time. The endpoint we’re going to hit here to specifically get the products in that store is /api/v1/products/get_all , with the type being product. Your GET would look something like this:

--url ''

Note: The page_size parameter in this call is set to 100, so the response will get you items 0 through 99.

Get the next page of results

If there is a next page available, the previous response would also include link for the the next page of results:


The next page link in previous response includes skip_count parameter value. The skip_count parameter is there to set the starting point for the next page result sets. For the purpose of this example, the Skip_count value is 99 and so the next page of results will show items 100 through 199.

--url ''

How do I know if there are more pages?

When the response doesn’t contain a link to the next page of results, you know that you’ve reached the end.