Getting all followed streams including offline

GET https://api.twitch.tv/kraken/streams/followed always just returns live streams for me, adding stream_type=all does not change anything. Shouldnt all also return offline streams? If not, how to get them?

I guess I have to use GET https://api.twitch.tv/kraken/users/user ID/follows/channels ? How would you even know your own userID … it would force you to ask for your own channel name, then do a query for this channel to get a userID.

I don’t really know btw which genius came up with the userID change for V5… it is just a mess. It makes things way more complicated then it should be. It adds now a 2nd get query every time, where the Twitch SQL servers should do this on the fly, where they have the information anyway… No one would every query things by i d from outside, always via name. It doesn’t make sense.

Streams are live broadcasts, so the channel will only show up when the person is live broadcasting. Our glossary defines the terms. :slight_smile: I think you’re looking for the Get Channel by ID endpoint.

User IDs were necessary for name changes. There are a lot of APIs that refer to users by ID. Facebook, Twitter, etc. We do have the endpoint to get the user object by login, and you can send up to 100 logins to the endpoint: https://api.twitch.tv/kraken/users?login=dallas

It doesn’t make sense for referring by id from outside the api. Because you will always search for a channel name or user name… and now you totally blew it up, by having to do a second obsolete query everytime to your api to get the id first. This totally messes the whole thing up, and forced a DEV to store a local name/channel=>id database to not making obsolete and nonsense queries. At least you could have let both API endpoints coexist, not just the id…

Thanks for the feedback.

User id’s exist, at least partially, because of username changes. They’re a constant value that identifies a user. Using a username as a primary key for any kind of data storage would be a poorly designed implementation.

No… you don’t get it… of course it would be bad design INTERN, in the database, there an Id need to exist. But it doesn’t make sense from outside queries, especially not, because the search String is KNOWN, the moment you do a search… Your statement “because of username change” doesn’t make SENSE. You’re not searching (do queries) for usernames… you’re searching for CHANNEL names most of the time and these are KNOWN the moment you search.

If I want to search for Dansgaming… I know what I want to search for. 1 query. And now, your have to do at least 2 queries… THIS is bad design.

It would be like you want to search for “diablo” and your API wouldn’t have an access point for game names, and you would have to do a 2nd query to get the game Id first.

Bad design… and it’ just a MESS. Now I have to save my own database on local disk for my app, and store names=>id in it, to not have to do obsolete API calls all the time.

I see what you’re saying, the requirement of two calls to get information of a user identified by a username, sure. Create a cache and maintain username->userid like you said. But, the problem goes beyond this usecase I think. Are you suggesting their api return usernames as well? If that’s the case, the data returned could potentially become invalid as a result of someone changing their name. Their v5 api returning userids ensures that the returned data cannot be invalidated by a username change. The idea here is to streamline all services into using userid as a key which will (theoretically) never change and whose data can be consistent. That isn’t possible with usernames.

Most applications will only be doing this username -> ID lookup once per user when they start tracking that user. The overhead there is minimal and drives applications to track users by ID instead of username, making sure the same person coming back will be treated as the same user, even after a name change.

But, it’s a significant overhead for simple applications that do not track users over time (every API request turns into two), which I think is what @mkdr is talking about. I agree that it would be nice to have a way to request directly by name on all endpoints where applicable for this reason, however, it would need to be in a way that still encourages developers to track by ID. I don’t think now, during the transition period from v3’s username tracking to v5’s ID-based system, is a good timing for adding such feature though.

1 Like

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