Hi @george, here is my feedback with regards to my use case/product.
Right off the bat, I have 2 processes that scan the list of games and live streams, page by page sequentially. I am OK with the 120 req/min limit for those. Additionally, my system may occasionally scan the list of live streams for a particular game, but I can probably fit that too within the 120 req/min for my Client-ID.
However, my system is a single page application (SPA), and users that log in through Twitch also get to see the list of streams they follow, whether the streams are live or offline. Since it’s an SPA, my intent is to refresh the list every once in a while in the background to keep it up-to-date and notify the user when a stream goes from offline to live. It is imperative in my case that the rate limit here is only applied for each specific user / OAuth. Imagine I have 20,000 users online at the same time, and each user follows around 500 livestreams, that means I need about 5-6 HTTP requests per user to refresh their whole list (since page size is 100). That would mean I have to funnel about 100,000 HTTP requests in a 120 req/min rate limit on top of my catalog queries mentioned in the previous paragraph. That would take over 13 hours, which is astronomically higher than what I need. I’d like to be able to refresh each user’s list every few minutes or so.
Can we get confirmation that certain API calls, like lists of followed channels for a given user, will only be rate-limited by user ID + client ID combination, as opposed to client ID only?