HTTP 410 on GET


First question:

Do you know what happen to the get user api (GET HTTP/1.1) in the last 2 days. It was returning HTTP 410 (Gone) for a long time. To be more precise between sept 5th 17h30 to sept 6th 18h UTC.

We haven’t found any traces of status saying Twitch api were degraded, but we were receiving errors for a day

Second question: is about to be deprecated? If yes, when?


  • September 5 – 24 hour shutdown starting at [11:00am Pacific ]

Everyone has been well informed for years now of the shutdown of v3, and the announcement even details specifically the times/duration of the controlled shutdown in the lead up to the complete removal of v3.

If you’re still using v3 in your code you need to immediately migrate to Helix!

Hello @Dist

Many thanks for your rapid answers. Unfortunatly, I was not aware of this change. It did not reached our team. I am working for Ubisoft and we integrate session validation in our backend using:

Authorization: OAuth -the token obtained on the client app-
User-Agent: TwitchAgent

At the very moment I am not sure how difficult it is to migrate the what you call v5. But I would appreciate your hints.

1- Does it requires client changes?
2- It is manageable to change only our backend to change the way ve validate the token received from the client? If yes, how trivial it is? only an url change?
3- Since Ubisoft have important integration using Twitch, is there anyway to postpone the complete shutdown before we get ready?


  1. Anywhere that you’re making Twitch API requests will need to make changes.

  2. A short-term solution is to change from v3 to v5. This can be done by either adding the Accept: application/vnd.twitchtv.v5+json header to the request, or api_version=5 as a querystring param for your requests to or any other Kraken endpoint.

Please keep in mind though that v5 is also deprecated, but has no removal date as of yet so should remain for the coming months ahead.

  1. I don’t speak for Twitch, but honestly it is most likely no to postponing the complete shutdown. Twitch have sent numerous emails to developers over the last couple years, v3 has been completely removed from the docs for over a year, and the docs have also contained both migration info and deprecation warnings for a long time, so if you’re still using v3 then the fault lies with the maintainers of your software. Leaving it until less than a week before the complete shutdown is not good development practice.

It is also important that you update the URL’s used in any OAuth flow you may be using, as if you’re still using v3 endpoints it’s likely you’re using old OAuth URLs (these can be identified by having ‘Kraken’ in the path), and the new OAuth URLs should look like for example. Please read the auth docs to see which URLs you need to change: this should just be a simple case of swapping out the old URLs for the new ones, the actual process/params haven’t changed.

1 Like

There is also a migration guide here

That may help or speed your migration

As dist says, all you should need to do is swap the header to be v5 instead of v3 (or add a header if you were not sending one in the first place)

v3 is the default API version and developers will need to set an Accept header to specify that they want to reach v5 endpoints. Developers can proactively include the v5 Accept header in order to properly test their updates. Below is an example and you can visit the Requests documentation for more information.

Is the key point from the Migration Guide.

For the URL you are calling /kraken/user you just need a new header. And then handle any keys that are not in the v5 output, but login/display_name are unchanged.

For session validation you may want to look at the “validation” endpoint instead

Which is neither a kraken (v3/v5) or helix endpoint

1 Like

Hi again

I will have to reach the teams within our organisation that implemented the clients side of the applications integrating the Twitch api. For my part, I am simply responsible in the flow to receive the token, validate it, and obtain Twitch profile identity.

I have just tested the addition of v5 as a query param and it looks positive. I haven’t identify any api breaks that would prevent me to simply change the url used by our backend from the broken one, to the one with the query param v5. Sound like a good short term option.

So if I understand correctly, the v5 will be deprecated as well, but not super short term. It will give us enough time to look into the latest and greatest api.

For upcoming changes, what is the best way to be notified? I just created this Developper account, so I guess from now on, we should receive an email for the upcomming changes.

Again, thank for your help

For things like the auth process and validating a user there shouldn’t be too many changes. The most significant change from v3 to v5 if you’re using any other endpoints is that any requests that use the username in the URL path instead use the users ID in v5. So for example if you used you would instead use in v5.

Correct, v5 is deprecated but no removal date yet. As Helix (the new API) is still in development this means that v5 will continue to be supported until Helix has feature parity with v5, at which point they will start giving out warnings and plans for removal (this likely wont be until the 2nd half of 2020 based on how long v3 has taken to be removed).

A developer account should let you get emailed about important changes, but I also suggest going to the Announcements section of these forums and just to the right of the ‘New Topic’ button is a notification button which you can toggle to give you notifications any time there is a new thread.

Any major updates will also likely be mentioned on but that’ll most likely link back to these forums anyway but that’s another option to monitor for news.

Hello again

We are testing this change at the moment:

Token endpoint: Change from to

User endpoint: Change to

Do you confirm that with those two changes we are now on the safe side for the deprecation planned on Sept 12th?

Best regards

As per the migration guide

The Preferred method is to use a HEADER. NOT a query string argument

v3 is the default API version and developers will need to set an Accept header to specify that they want to reach v5 endpoints. Developers can proactively include the v5 Accept header in order to properly test their updates. Below is an example and you can visit the Requests documentation for more information.

The Query String argument is undocumented and can change or break at any time.

That should be sufficient to make the API request part of the process work, but depending on how you use the data returned you may need to make other adjustments as one important difference between v3 and v5 results is that in v3 the _id field is treated as an integer, where as in v5 (and the new Helix API) it’s a string.

So if you’re making use of a users ID, such as in a database or whatever, make sure that the change from an int to string isn’t going to be an issue for you.

A less important change, but still a change, is the removal of the _links object in v5, so ensure you’re not making use of that.

Thanks again

Oh indeed, the type changed. Will look into this
For links, we are not reading that value. So we are safe.

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