Requiring OAuth for Helix Twitch API Endpoints


Why is asking your users to log in not an option? If they are using a client-side app then it is reasonable to ask that user for permission to make API requests on their behalf (ie, get an OAuth token from the Implicit OAuth flow, which is design for client-side apps).

There are also free/low cost servers or serverless infrastructure available such as that offered by AWS that can handle an OAuth flow and deal with an API requests on an on-demand basis so you don’t pay anything except for when you actually make requests and even then they have free tiers on many of their services.

If you’re still not able or willing to do either of those options then yes it looks like you will be out of luck. Requiring accountability for who is making requests is not something that is out of the ordinary, most services online that offer 3rd party APIs usually require some for of OAuth token or similar authentication token to access their API endpoints.


The request to “/helix/users” mentioned at the top as a sample request according to the API documentation does not require auth. So does this mean, that this call will require auth in the future? I guess so, as @jbulava writes “OAuth will soon be required for all Twitch API endpoints in the new Twitch API”. But when will this be reflected in the API documentation?

This leads me to my actual question: Is there a way to test this?
I have a tool which does lots of API calls from my server to the Twitch API. So as far as I understand I will need an “App Access Token” in the future. No problem, that’s easy to acquire.
The problem I have right now is, how to test this? I tried to pass garbage as “Authorization” in all of my request headers. Expected to get an error from the API. The Twitch API responds with the requested data regardless of what I send in the “Authorization” header. So it seems I have no way to test if my code is ready for the upcoming changes.


When you specify a valid auth header, it’s valid so no error is returned.

But you do get a higher rate limit, currently, with just Client ID you get 30 requests, with any valid auth token you get 800 requests. So in short, check the response headers for the update rate limit values.

ratelimit-limit: 800
ratelimit-remaining: 799
ratelimit-reset: 1582980153


@BarryCarlyon Thanks, that helps a little bit. I’ll implement some tracing that checks if the rate limit of all my calls is returned as 800. That gives me at least a chance to figure out if I correctly implemented my token acquisition and caching system.

Still find it strange that you can post garbage data to the API and it silently ignores it :laughing:

#46 related issue