Today we are announcing the timeline to decommission the Legacy Twitch API v5 with the shutdown to be completed on February 28, 2022. Twitch application client IDs must migrate to the Twitch API by February 28, 2022, and those that have not made requests to the v5 API before July 15, 2021 will no longer be able to access v5.
The information below includes key takeaways and the shutdown windows leading up to the final decommission date. For greater detail regarding this shutdown, please see the Twitch blog post entitled Legacy Twitch API v5 Shutdown Details and Timeline.
What’s changing?
The Legacy Twitch API v5 has been deprecated for some time and as of today has a scheduled shutdown timeline. With the latest endpoint additions, the Twitch API now includes all the functionality that we intend to migrate from v5.
Why are we making these changes?
For further details regarding why the Legacy Twitch API v5 was deprecated and scheduled for decommission, see the blog post linked above.
Who will be impacted by these changes?
All developers who are currently using legacy v5 endpoints in their applications.
What action needs to be taken?
Refer to the v5 Migration Guide which provides endpoint equivalence and migration paths, as well as scope equivalence to help ease the migration for your users.
A bunch of endpoints are simply not supported in the new API. Are you planning to support any of them before the shutdown? If not, what happens to applications that need that functionality?
Following today’s update, the v5 migration guide should mention all v5 endpoints in the table to explicitly state if each one has a migration path. The few endpoints that state they are “[n]o longer supported via the API” are not planned to be provided by the shutdown date in February 2022.
Now that the decommission details and timeline have been announced, we will soon be updating UserVoice suggestion statuses related to v5 and checking them with the teams that own each product before doing so.
Okay, thank you. Can you get the migration page updated to say that these APIs won’t be shut down, please? It’s kinda important to those of us who use these.
Apologies if my wording wasn’t clear. The migration guide is updated and accurate. There are no plans to support the few endpoints that do not have a migration path.
I will be making sure product teams are aware of all open v5 UserVoice suggestions and double checked before replying with specific context.
As mentioned: For some things, there is no migration path because the usecase is no longer supported.
For those things that do have a Migration Path, see v5 Migration Guide | Twitch Developers
As for the “Get User Emotes” Endpoint, specifically: to reconstruct the usecase this is used for, you will need to capture the Emote Set IDs via IRC (See here) and then utilize the new Emote Endpoints in Helix to resolve the Emote set IDs. (See here)
Yes, there are inconsistencies there and there are uservoices to clarify some things. Vote for the Uservoices that indicate your missing usecases!
Ran through the list myself real qucik, and the get all chat emoticons endpoint is the only one that is not on the list.
Given this catch-all statement I assume there is no intention to support it right now. As such I created a uservoice to create an equivalent. (I thought I did this when the new emote endpoints were released, but I must have forgotten)
The emote sets given via IRC are not sufficient. The use case is listing all emotes available to a user - for example, for a custom chat client. There is NO WAY TO LIST A USER’S EMOTES. Pardon me for shouting, but this is a very very real use case that is being completely ignored.
Listing emote sets is not sufficient because a user may not have access to every emote in that set. For instance, if you cheer 1000 bits in a channel, you gain access to one of that channel’s bit emotes, but you are listed as having the entire set.
The best place for stating your use case is Uservoice rather than this announcement post.
If there’s not a suitable solution in Helix then you may simply have to do without such data. Even if I agree with you that it’s a great use case for such data there may be technical or design considerations you don’t know which have limited any implementation in Helix so far.
And UV already has multiple such posts. I’m not responding here because I have any real hope that this will be fixed, but more just because everyone keeps saying “it’s okay, use the IRC set list”, and no it is not okay.
It may not be to your liking, but if the IRC set list is what we have to work with, along with any existing Helix endpoints, then apps will have to adjust to that situation. People are trying to suggest alternatives because while they may not fit your perfect little app, we all have to work with what we’ve got and that does mean that some features we may like to implement in our apps are simply not viable, or will have to make do with limitations/
Thanks for calling it out.