next_href is defined even after the end of the results

[LucaDiba]

Hi team. In search results, the following request:

GET https://api.soundcloud.com/tracks?linked_partitioning=1&limit=50&offset=1000&q=Daft%20Punk

Should have the next_href field defined only if there are other pages.

This is the current response:

{
  "collection": [],
  "next_href": "https://api.soundcloud.com/tracks?linked_partitioning=1&limit=50&offset=1050&q=Daft%20Punk"
}

I feel like having a next_href with 0 tracks should never happen. If that's the expected behavior, the docs should probably be updated:

To fetch the next page of results, simply follow that URI. If the response does not contain a next_href property, you have reached the end of the results.

[mgoodfellow]

It might be due to track visbility/access issues.

There is an oddity in the user/tracks endpoint, whereby if you don't have access to the track it won't be returned in the collection. This can lead to either getting less tracks than you expected, with a next_href, or even, no tracks, and a next_href.

I'm not sure this affects the core /tracks endpoint as well - but it might be interesting to continue paging if it believes there is more data, and see if you start to find more.

From a few years ago: #55

Hope this helps :)

[dpreussler]

Indeed that is probably the problem here.
A workaround would be to asked for all access and do the filtering on client side, see access parameter https://developers.soundcloud.com/docs/api/explorer/#/search/get_tracks