New Twitch API Follower Endpoint and Redundant Data

API
1

First off, i am very happy that Twitch is reducing the amount of data that the New API Follower endpoint provides. The previous API’s sent so much superfluous data.

However, the new API Follower Endpoint has one bit of redundant data that is just glaring back at me.

When I make a request for who is following my channel, why does each and every entry need a copy of MY channel’s User ID in it? Wouldn’t that information be obvious, since I am requesting the list of people following me?

Secondly, with how much redundant data has been removed from the Follower response, why keep the returned data limited to 100? As has been mentioned in a previous thread on the topic, Twitter’s API allows for a simple array of UserIDs, and packs in 1000 or more into a single response.

For example, my channel has around 12000 followers. Every so often I do a full pulldown of all the followers to see who is still following, and to detect if there were unfollows. With the 100 follower limit, I still have to download 100 max followers at a time, which is 120 requests.

If there was a way I could tell the endpoint “just send me the IDs of users following me, sans-follow date and my own twitch id, and send them to me in bulk 1000 at a time” i could cut my requests down from 120 to just 12.

That being said, I do not know what types of processes are running on Twitch’s end to gather said data, so there could be more going on from the data collection side of things than I realize.

Personally, being able to add two flags to the Request URL, “to_id = false” and “followed_at = false”, to clip that data from the response, and just send an array of User IDs in follow order (plus more than just 100 at a time) would be help to optimize deep pull requests for follower lists.

1 Like
2

Likely to maintain consistency where you are requesting to_id or from_id so you don’t need to handle different result formats depending on which parameter is specified.

3

Which is a good point, consistency across endpoints and requests. I guess my brain just looks at API requests as “how can I get the most relevant data with the least redundant data with the smallest request footprint.”

The follower endpoint being, quite possibly, one of the most requested endpoints in the API.

The “Get users” endpoint, on the other hand, is great since multiple users can be requested at once. So if I poll the first page of Followers, i can then send the newest User IDs as a single request to Get Users, rather than individual ones.

Guess its give and take when it comes to the two of them. Same number of requests to Followers as before, MUCH less redundant data overall compared to V3 and V5, but also less overall requests needed toward Get Users since it can be bulk requested

4

The reason we include your own ID is as george said, we want to have a consistent model regardless of whether you specify from_id or to_id (or both!).

The max limit of 100 is due to the cost of fetching the following list. That said, it’s not impossible for that limit to be raised in the future.

Finally, I would hope that the following webhook would help you reduce scraping of your follower list and may address your concerns. (releasing Soon™!)

5

WebHooks will be wonderful. I do need to do more research over the topic from a general standpoint to see the best way to implement it into NodeJS (there are bound to be modules available on NPM for that).

On the topic of WebHooks, assuming there is a “New Follower” WebHook, would there also be one for “Unfollowed”? And could a feature be added that shows if the new follower came in from a physical press of the follow button on the channel page (where the chances are the person is actually viewing the stream and followed because they liked what they saw) vs the Twitch App Onboarding process (where the person never has to even view the stream to follow).

6

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