@Six Are you testing from multiple machines? That’s what I am addressing. The script does 130 requests as fast as possible. “Success” is 120/10 or 30/100
See how it’s always limited by IP address, not by client-id?
Also this convo is extremely off topic. The main issue being addressed is how to escape the limit because there is no “unfollow” or “unsubscribe” or “viewers follower/subscriber” data which requires doing a number of API calls beyond the scope of the current limit that Twitch gives. A single user would have to auth 5-10 client-id’s.
@Six I think I realized why I am seeing what I’m seeing. I am testing using a US and Canadian proxy. They resolve to different places for the twitch API. I’m guessing they have multiple datacenters split up by region. Their rate limiting would make sense to be per-region as making that data sync isn’t worth it, as it’s about performance. I’m going to run my tests using two local US proxies instead.
@Six Confirmed. It’s because it’s multiple regions. I was seeing different behavior than you because of the locations I was using to run my tests. I used local instances and I am being blocked by client-id.
Sort of at a loss here, because how am I supposed to build a popular twitch app that only does 120 requests per minute. What if I have 120 users? That’s one API request per user? That’s impossible to scale. And the endpoints I want aren’t available with just client-id.
I’m at a loss here. The only solution to this problem seems to be to create 1,000+ clientids and bake them into my app using a random distribution. I feel like twitch would not look kindly upon that.
For now I think my suggestion here is to revert to the v5 API since that isn’t rate limited. And hope twitch comes to their senses on the New Twitch API and realize that phones are an actual market that exists in 2017.
Limits need to be per-oauth not per-client-id. Per-client-id doesn’t scale.
People talking in chat have a subscriber tag/badge
Theres three event systems right there…
And too much work/information to display for the streamer.
How does a streamer knowing people unfollowed during a stream help a streamer there and then, given that most streamers (even more so the larger ones) will have follower only mode, (to prevent drive by spam) so tracking followers/unfollows is mostly irrelevant
PreHelix, you can’t
PostHelix you can’t
There are no bulk end points, you cannot easily get followers fully, even with Cursor’s in place you are still behind on large channels. I don’t think individual user followings is actually a relevant metric for you to display to your streamers (in bulk). Yes click a viewer to get more info on that particular viewer, and thus load that viewers status there and then.
You have to think of this from Twitch’s point of view also, it’s not practical for the followers information to be “easily” provided, except during the follow “on” event, anything else adds significant load to the whole system [citation missing, index corrupted]. And further more with an unfollow event can result in abuse (in the form of people going “hey I saw you unfollow x, why did you do that”)
Glad to hear you figured out what was going on, though. Hopefully scaling will be addressed by Twitch at some point once they realize the needs/traffic of the Helix API.
And you probably could have guessed this from your new results, but I was indeed testing on one machine from one location.
Still waiting on those helix folks to come by and tell me everything’s going to be okay.
If v5 is dropped and I am forced onto helix I don’t know what i’m going to do.
At least you have a little over year left to continue to sue Kraken v5. That should hopefully be enough time for the API use cases and requirements to be ironed out, as well as add more support for Helix.
Hi! Helix staff here. I wanted to reach out and explain a little bit what’s going on. Yes, we have rate limits, and they exist not only to protect us but also to protect you. We don’t want anyone to unexpectedly hammer Twitch and bring down your applications. We believe that your rate limit should scale with the number of users that are using your application, and we’re finishing up the pipeline for requesting rate limit increases. Expect a forum post about this soon. What we don’t want: you making hundreds of client_ids. That’s against our ToS. What we do want: you engaging with us such that we can serve you best, and keep the platform safe.
With regards to your application: we actually had a long debate about unfollow Webhook events. We deemed that unfollow events could actually be used for harassing purposes, and decided to not include them to promote positive environments. We’ll reevaluate and see whether this is something we do want to support after your feedback. No promises, but just wanted to let you know you’re heard.
Thanks so much for your feedback! We really appreciate it, and we definitely want to help out.
