Good Morning,
I’m building a data collection system for something that needs to be operational by Jan 1, and doing my very best to use Helix where I am able. According to the documentation:
Our previous API had a suggested rate limit of 1 request per second. The new Twitch API increases this limit to 2 requests per second and automatically rate limits applications based on use. If you go over the rate limit, your request will fail with an HTTP 429 response. Requests are counted over a 60-second window.
When you make an API request, you will receive a set of rate-limiting headers to help your application respond appropriately. The headers are:
RateLimit-Limit — The number of requests you can use for the rate-limit window.
RateLimit-Remaining — The number of requests you have left to use for the rate-limit window.
RateLimit-Reset — A Unix epoch timestamp of when your rate-limit window will reset.
Individual endpoints may have additional rate limits, with additional headers to describe those limits. For details, see the documentation for each endpoint.
I’m not seeing any information on the Streams endpoint that suggests a lower rate limit for that endpoint, but when I make a first request, I get these headers:
{Ratelimit-Remaining=[29], Ratelimit-Reset=[1511282710], Ratelimit-Limit=[30]}
Parsing this out, it looks like this:
Limit: 30
Limit Remaining: 29
Current time: 2017-11-21 11:46:43.601
Limit reset: 2017-11-21 11:47:40.0 (almost a minute after)
I stumbled upon this when I set my requests to delay 500ms between grabbing the next page and I was still getting 429 errors.This suggests to me that the limit for the streams endpoint is currently set at 30 every minute, which is one-every-two seconds, not two-every-one second. Is this the way it is intended?
Jeremy