This started happening a few days ago and then was fixed after an hour or so. Today, it started happening again.
Requesting /api/channels/CHANNEL/access_token.json with a 3rd party client-id results in a 410 gone error. However, requesting the same API endpoint with the client-id from the Twitch.tv website works.
What is going on? Is this a bug or has Twitch started to actively block 3rd party applications?
I am fully aware of this, but since there is no alternative to this, 3rd party applications have to use this endpoint. And it’s been used for the whole time now for several years. Now suddenly, it’s broken, but only for 3rd party client-ids, which is strange and raises a couple of questions.
There already are several 3rd party application developers which are now embedding the client-id of Twitch’s website in order to make it work again. I don’t think this is a proper solution and actually abusing the system.
What’s also a bit weird is that it already broke two days ago, but only for an hour, and then started working again. I would like to know if this is a bug or an intentional change, for example in order to stop certain people from view botting or so.
Btw, it’s not just /api/channels/CHANNEL/access_token.json, but the entire private /api namespace which is affected by this change.
Since Twitch does not provide every feature on /kraken or /helix, many app developers have to use certain /api endpoints. As I’ve said, simply using the client-id of Twitch’s website doesn’t sound like a proper solution and more like abusing the system.
I would appreciate if we could get a statement in regards to this change, as it is causing massive issues today for 3rd party app developers like me. Thank you.
It’s unlikely Twitch are going to make a statement. It has already been said, numerous times, that if you use these undocumented endpoints you use them at your own risk as they can and will change/break.
Changes/removal of some of these undocumented endpoints were somewhat known, and if you continued to use them up until the point they changed or were removed then that was the risk you took knowing full well that it was likely to happen at some point.
If you don’t want issues like this in the future, don’t use endpoints that Twitch never intended for 3rd parties to use. If that means you’ll be lacking certain pieces of functionality in your app then either accept that Twitch don’t want 3rd parties to have that functionality, or risk trying to circumvent restrictions Twitch are placing on this endpoints and further risk your apps (and potential violation of the developer agreement) future.
If these endpoints aren’t intended for us to use, why can we make client IDs that work with them? I could see that being a valid response if there were no way for us to use these endpoints with proper authentication, but that’s not the case. We can make client IDs for applications to use these endpoints.
As is, in order to make applications that work with Twitch fully, we have to figure out these endpoints entirely ourselves. It would be nice if these endpoints were properly documented and supported. Twitch clearly supports us using them otherwise we wouldn’t be able to use our own client IDs with them. It would just be nice to get some actual support and documentation here.
Just because you technically can access those endpoints, or at least used to be able to with a 3rd party client id, that is in no way an endorsement by Twitch that they ever intended for 3rd party apps to access those endpoints.
Saying that “Twitch clearly supports us using them” is nonsense, every statement by Twitch on the use of undocumented endpoints has always been that they are not intended for 3rd party use, and that they can and will change, break, or be removed, without any prior warning.
If you wish for Twitch to create endpoints that return the data you need that’s not currently available in the API designed for 3rd party developers, please suggest that idea so that Twitch can see what level of demand there is for such endpoints and if your use case for that data is legitimate https://twitch.uservoice.com/forums/310213-developers
My point was that Twitch could make these endpoints not work with our client IDs, yet we’ve been able to use these endpoints with out client IDs for years. Our client IDs do work with these endpoints which suggests that, despite what you claim, Twitch does support us using them.