Kraken: /streams/followed not ordered by viewers

The /kraken/streams/followed endpoint seems to be broken right now and the returned list of streams is not ordered by viewers, which it should. Could one of the Twitch devs please take a look at this? Thank you!

$ curl -s \
  -H "Accept: application/vnd.twitchtv.v5+json" \
  -H "Client-ID: CLIENT_ID" \
  -H "Authorization: OAuth MY_OAUTH_TOKEN" \
  "https://api.twitch.tv/kraken/streams/followed" \
  | jq ".streams[].viewers"
508
27329
293
2780
344
15
1278
43
232
437
756
1254
3768
898
79
5648
197
403
7
117
522
1 Like

Can confirm.

BTW…The sorting now is by followed (created) AKA the streamer that you fallow for longer will show in the list at the top.

Simple test follow a random stream or unfollow/fallow a channel, will show at the bottom of the list…

I try some options for sorting (sortby or just sort) that work in others API call, but noting works on this…

The docs for that endpoint, Reference | Twitch Developers, don’t specify what order the results will be returned, so you shouldn’t expect it any certain way and should be doing any sorting yourself on your end to ensure the order is the way you wish them to be ordered.

Sorting is not listed as an valid param for that endpoint, which is why it wont work.

But why suddenly change it and break it for everyone?

We don’t know why it was changed, maybe it was a bug, maybe it was intentional or a side-effect of a recent change.

Regardless of the cause, you shouldn’t be designing your apps that assumes data in any particular way that isn’t guaranteed by the endpoint. The docs for some endpoints specifically mentions that the results are ordered in a specific way, this endpoint has no such assurance, so you should design your app from the start knowing that you may get results in any order and so handle that as such on your end.

This is complete nonsense, because by providing pagination parameters (offset and limit), the user of such an API endpoint has to assume that the returned list is sorted in some way. And since there is no request parameter for changing the sorting, like for example on the followed channels endpoint, a static sorting of some kind has to be assumed. However, the list doesn’t seem to be sorted in any way. And if it is, then the sorting is completely useless and works against pretty much every consumer of the endpoint, since they are most likely (definitely) expecting a list of streams sorted by viewer numbers, just like on the overall streams API endpoint.

Sorting on the client side, like you are suggesting, is an absolute no-go, especially on any network related data retrieval, or do you also fetch every row from a relational database query response in your own native applications and do the filtering and sorting afterwards? Probably not, because that would be totally ridiculous.

And by the way, the followed streams list on the kraken API has been sorted by viewer numbers ever since I’ve started building my Twitch application in 2013. And now, all of the sudden, it got changed. If it was an intended change, then a sorting parameter has to be added by the API devs for the reasons stated above (not to mention that Twitch is introducing a breaking change here for whatever reason), and if it was an unintended change, then we all have to wonder whether Twitch even still cares about its deprecated kraken API, which is weird though, because the new helix API namespace is still a total disaster.

4 Likes

Can we have an official statement on this? Sorting the whole thing is not a big issue on the consumer side, but the fact that the change that caused all this also affected the rerun visibility ( they are not showing up in the response anymore ). And that we can’t fix on our side.

Sorting the items of the API response on the client side is “not a big problem” only if a user doesn’t have followed hundreds or thousands of channels and the response remains below the request limit of 100. Otherwise you’ll have to chain API requests with increasing offsets, cache the results, filter out possible duplicates which may have occured between the requests, sort the entire list and then return it in chunks (or as a whole). This is nonsense and can’t be in the interest of everyone.

I too would appreciate if we could get an official response from one of the Twitch API devs. Having a streams response sorted by the date the user has followed the channels is just bad and doesn’t make any sense. Also please remember that the API endpoint is /kraken/streams/followed, which already implies that it should be sorted by viewers, just like /kraken/streams. If this change was intentional for whatever reason, then please consider adding a sorting parameter, so that the previous API behavior can be restored. Even though Twitch has deprecated the kraken API namespace, breaking changes like this should not be introduced.

Thank you.

Even if they respond on why it changed, as stated, the documentation never specified a sort order, so you can’t assume it will be sorted. If they specified in the docs it was sorted, then yes, it would be a breaking change, but since that is not in the specs, its not a breaking change API wise. It may break you app since you assumed it, but that isn’t on twitch to maintain or supply the data in that format. They only need to respect the documents they published.

Anyone suggesting that this API endpoint did not have guaranteed sorting is not familiar with how pagination works. How can you possibly have paginated results if the results are not guaranteed to be sorted in a specific manner? bastimeyer is 100% correct here. There is no way this API endpoint could be used reliably with pagination if the results are not guaranteed to be sorted in the same way every time.

I disagree. Pagination only breaks apart a large result set, which can have any order you want as long as you keep track of what you’ve sent and what you haven’t.

If an API consumer accumulate the items from first page, follows the cursor, accumulates the items from the next page, and continues doing that until there is no more items, they are still receiving the full result set in the original order (which could be totally random as far as the consumer is concerned).

Maybe Twitch is now sorting these by some public or internal id, but that doesn’t mean they have to expose it. From an API provider perspective it might even be easier to implement it that way because an id is much more stable than viewer counts (whereas if viewer counts change between requesting two pages you might have duplicate items).

This API endpoint is now back to being sorted by viewers. It’d still be nice if Twitch were far less silent on issues like this.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.