Correct, as of today.
Yes! I realized it during our broadcast Thanks for calling it out.
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.
Oh. Then we need a migration path, please! You’ve put yourselves on a time limit here.
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/
“perfect little app”. Nice respectful language you’re using.
I can’t believe that something as important as offsets for clips hasn’t been implemented in the new Twitch API when it’s something that Twitch itself requires on every single clip page. (The “Watch Full Video” link needs this in order to start the VOD when the clip occurred.) Please vote for the Extend clips API to return the offset/start point UserVoice because this is critical information both for developers as well as Twitch.
This has been brought up before and offset was mentioned as not being added at this time. Hopefully this is reconsidered though as we progress towards the announcement timeline.
Will we be getting updated_at field in Get User(s) that exists in V5 API?
I would expect the
updated_at field to be intentionally left out of Helix for privacy reasons and lack of legitimate use cases.
One concern or question I have is regarding the information regarding if an account is “verified” bot or not, which is an endpoint today in Kraken API.
Which today returns “is_verified_bot” & “is_known_bot” and from what I have seen, there has been no such endpoint yet for Helix. Is this something that would be added before the end of life of kraken?
While that endpoint is part of the Kraken namespace, it is an undocumented endpoint so as with all undocumented endpoints it can change/removed at any time.
Feature Requests for Helix should go on Uservoice Developers: Top (509 ideas) – Twitch UserVoice
That might come when the update to An update for the delayed bot verification request process is posted with a better way to see the status.