

Since some of the private API endpoints require authentication data, OAuth tokens generated from third party client-ids can't be used anymore. The token is not just tied to the user, but also to the application's client-id. An OAuth token is a login key generated by Twitch after a user has successfully logged in on their website or a third party application which requested authorization. The reasons for this are unknown, and we probably won't ever know, but it could be related to the API changes of their new website which I just talked about, or other things like a new view-botting prevention, etc.Īnother issue are API requests which require or where you can optionally add authentication data with a so called OAuth token. Instead of allowing third party applications to access the private API namespace, they now have started to restrict access to it, so only their own client-id can be used. To come back to the problem, what has changed is how Twitch reacts to private API calls with third party client-ids. This client-id is public as well, like every other client-id. The Twitch website is no exception to this and thus also uses its own client-id to make API requests. In return, they receive a public client-id, which needs to be sent with each API request. In order to access any of these APIs, developers of third party applications need to register an application name with their Twitch account. One of the few exceptions is the streaming access token, which still lives on the old private API namespace. This new GQL API is private and exclusive to their website as well and has replaced almost all of the old API requests they make on their website. However, when Twitch redesigned their website one and a half years ago or so, they also introduced a fourth API, based on a different tech (GraphQL). This private API namespace was used on Twitch's old website mainly for hidden and for newly added features or experiments. That is why Streamlink and Streamlink Twitch GUI needed to access a third, private Twitch API namespace, /api, which is not intended for 3rd party app developers. Both of these API namespaces unfortuantely do not provide the necessary endpoints for retrieving essential data like an access token needed for watching streams, or reading other data like followed games/categories, etc. Twitch officially provides two API namespaces, /kraken, the old and deprecated namespace with v5 as the current version (v3 has been shut down this year), and /helix, the *new* and rate-limited, and also still feature-limited namespace (different issue). Not just Streamlink, but all third party Twitch applications were affected by this. Let me quickly recap the whole thing and point out what has changed.Ī little bit more than two weeks ago, Twitch had started to restrict access to their old private API namespace and a 410 Client Error: Gone for url error was returned when requesting those endpoints, like for example when requesting a streaming access token, which Streamlink has to do before it can launch Twitch streams. Streamlink 1.3.0 has been released today with the fixed plugin (fixed in PR #2692).Īpologies for taking a bit longer, but as you all know, Twitch went back and forth with the API changes several times throughout the past two weeks and it wasn't 100% clear whether it was an intentional change or not, especially because of the lack of proper replies on Twitch's dev forums. The issue is also not part of the kraken API anyway which the version number is used for, so it's completely irrelevant. version=5 gets explicitly set when the class instance gets initialized. The version=3 parameter is the old default parameter value, but it's not being used. I fear there won't be any other solution, but hopefully I'm is not true.
#TWITCH LEECHER 1.7 SEARCH CRASH FREE#
If you need help or want to discuss the Twitch API situation, feel free to use the Streamlink Gitter channel:Īnd in case that these issues will continue, we will probably have to go the dirty way and use Twitch's own client-id for all private API requests in the future.


See this comment here if you're looking for a temporary workaround solution: We've already said and commented on everything regarding this issue and I don't think there won't be any more comments with more useful information. Before this ends up in another flood of posts, I'm going to lock this thread.
