Oddities in helix rate limit calculation

I’m working on a rewrite of my bot, which includes migrating to the new API. Aside from IRC and PubSub, the only thing it’s doing with Twitch right now is polling my stream status once a minute, with a followup query to the games endpoint when I go live if the game ID isn’t in the cache. Imagine my surprise, then, when I get a 429 error.

I invalided the OAuth token that it’s using (just in case, after all it’s been 3 years since I got it), got a new one, and started logging the rate limit header values from that once-per-minute query. What I saw was this:

  • 100/120 - 1527049890
  • 109/120 - 1527049950
  • 107/120 - 1527050010
  • 109/120 - 1527050070
  • 108/120 - 1527050130
  • 102/120 - 1527050190
  • 106/120 - 1527050250
  • 111/120 - 1527050310
  • 107/120 - 1527050370
  • 109/120 - 1527050430
  • 99/120 - 1527050490
  • 109/120 - 1527050550
  • 106/120 - 1527050610
  • 109/120 - 1527050670
  • 107/120 - 1527050730

There’s no other application connected to the bot’s account, and the OAuth token is brand new, so I should be seeing something more like 118-119 out of 120.

Ok, weird… the old and new tokens I was experiencing the above problem with were generated by the “Twitch Chat OAuth Password Generator” linked from the IRC protocol doc page. It worked well enough, as the only scope I needed was logging into chat.

I just generated a new auth token with my bot’s client ID, and I see what I would have expected to see all along… 119/120 in the returned rate limit headers. It makes me wonder what that 3rd party auth token generator is doing behind my back.

Never mind… just noticed that the limit is by client ID, so I guess I’m finally doing what I should have done all along.

2 Likes

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