410 gone when requesting private `/api` API namespace with 3rd party client ID

API
1

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?

curl -s \
  -H 'Accept: application/vnd.twitchtv.v5+json' \
  -H 'Client-ID: CLIENT_ID' \
  -H 'Authorization: OAuth OAUTH_TOKEN' \
  'https://api.twitch.tv/api/channels/CHANNEL/access_token.json'
1 Like
2

This is a undocumented endpoint.

It’s not intended for third parties to use. Hence it can change or break at any time.

3

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.

2 Likes
4

If that is the case, there likely won’t be a public comment made about it

5

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.

6

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.

7

3rd parties “should only” be using Documented endpoints.

Any endpoints not under /kraken/ or /helix/ cannot be expected to be relied upon, as they are “unsupported” endpoints that can break or change at any time.

You probably will not get a statement, as you were not supposed to be using these end points in the first place.

So in summary, you can’t get support for endpoints you are not supposed to be using as they are not documented for third parties to use.

8

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.

9

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

1 Like
10

Most of the endpoints under the /api/ URL have been used by Twitch internally to power the website, and now replaced by GQL endpoints.

(GQL is also an undocumented API that YOU as a third party should NOT be using)

And whilst they exist and were/can/are/were callable by Third parties doesn’t me we can/should.

They are undocumented, as in not in the docs, as they were NEVER intended for third parties to use.

And people like yourself used them anyway.

They will remain undocumented as you are not supposed to be using them, and have started to be blocked/removed from use.

So there will be no

for these endpoints.

11

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.

12

Incorrect.

If it’s not in the documentation located at

Then it is not supported for use by third parties or expected to be used by third parties.

Please stop arguing the point, I’m telling you how it is.

Well it doesn’t any more anyway:

Topic closed since you are not listening to what I am saying. About these endpoints that are not in the documentation being unsupported for third parties to use.

1 Like