I retract my now deleted comment, I was misinformed about emote set IDs and what value they had in identifying what emotes a user actually had. I was under the belief that every unique emote in Limited Time and Event emotes had an own setID as well, to identify what actual emotes the user had access to. As @zneix pointed out to me that is wrong, which just means that this endpoint is even more necessary than I previously believed.

Just in case folks missed it, this suggestion corresponded with the Twitch Emote API endpoints that were released in 2021. In those comments (link below) we mentioned there were intensionally no plans to offer the same functionality because providing the emotes that a user has access to would expose subscription details which should be scoped. That being said, subs are scoped with "user:read:subscriptions," so there is an argument to be made that an endpoint could potentially exist that, for example, provides globally available emotes and then include subscription related emotes as well if the subs scope is provided. Additional feedback is welcome given this context. We'll also bump this topic to the team to confirm if this is information we would provide if scoped somehow and investigate the value of adding it to the API if so.

https://discuss.dev.twitch.tv/t/announcing-api-endpoints-for-twitch-emotes/32073/15

Edit: Realizing after posting my comment that v5 _was_ behind a subscriptions scope, so there was likely even more concern about offering sub information in an emotes-specific endpoint (to your point below RealityRipple). Either way, will follow up to get a specific answer rather than leaving the status empty/unknown.

So we still missing the authenticated emotes. after v5 api down

This would be extremely useful for a myriad of purposes. Personally, I'd like to use it to parse tip/donation messages (payment memos) from authenticated users to be able to use them for emote-splosions (kappagens) on my home-made emote wall. As it is, I can support third-party emotes and emojis, as well as Twitch Global emotes, but the user's personal list is inaccessible without asking for "chat:read" permission and initiating a login to get the emote sets list from IRC.

Making this a public query would be ideal (allowing emote parsing of messages sent via third-party sources without requiring the user to give permission and trying to pass that permission through a third-party source [or via another token and temporary storage of the permission or the parse results]), but I understand if leaking who a user is subscribed to or how much they may have spent in a channel could be a privacy concern.

Been a few months now since Kraken was shut down and as a result some emotes such as Twitch Event emotes (New Year 2020 for example) aren't being returned in the new Helix API. Are there any plans on fixing this any time soon?

Not entirely sure how this went unseen prior to announcing and even shutting down the Kraken API.

I really hope this is still being considered, as of now when Kraken shuts down on Tuesday there will be no way for any 3rd party application to obtain the emotes for certain emoteSets, as some of the IDs return nothing via Helix's `Get Emote Sets`.
see: https://twitch.uservoice.com/forums/310213-developers/suggestions/43688652--get-emote-sets-enhancements

Unfortunately because of this, it will look bad on developers, as unfortunately many users see a missing feature and fault the developers, despite not knowing the reasoning why a feature is missing.

I am working on an Open-Source Twitch App and this API-Endpoint would be helping us a lot.

Currently devloping an iOS Chat Client and I don't think I can get a fully functional emote menu to work without this endpoint.

To add to this further, please also make sure that the correct set of smilies [ :) :( :/ ] is returned (robot, glitch or monkey), so it's clear which set will actually show up when sent by the user. This also currently appears to be the case with the Kraken endpoint.

@ScottRC While emote-sets tag from `USERSTATE` (and `GLOBALUSERSTATE`) are useful and give us all the information to look up emote sets by IDs I wanted to address the existing issue with that solution here as well - so far, these are the IDs of emotesets I've encountered so far that have the same issue as described by @Rosuav on the Twitchdev forums[1]: `472873131` `477339272` `488737509` `537206155` `564265402` `592920959` `610186276`. Trying to lookup those in Helix returns empty arrays as I believe that whether a user has emotes from those sets or not is tied to user's account.
The only alternative would be to use Kraken's Get (Authenticated) User's Emotes, but given today's announcement about Kraken decomission we'd need a way to query those in Helix. Many third-party chat clients (including the one I currently maintain) use this functionality and it's very important to us.

[1] https://discuss.dev.twitch.tv/t/announcing-api-endpoints-for-twitch-emotes/32073/16

To add to this, to get the most usefulness out of this it would be nice if the reponse would contain the following information for each emote:

* Name (what you would type in chat)
* Type (sub/bits etc.)
* Tier
* Channel id, channel name (Including the name, not just the id, means fewer API requests to get the name if it's required for something)
* Set id
* Animated (yes/no)

To add to this, the IRC USERSTATE emote-sets tag, should also include the new emote set ID's. The documentation doesn't seem to give devs any information that it excludes bit emotes etc. https://twitch.uservoice.com/forums/310213-developers/suggestions/43663572-irc-userstate-emote-sets-should-include-bit-emotes