Why would that be a problem though? The Kraken endpoint only works for the currently authenticated user and requires the scope for viewing subscription for said user. That’s all developers want from that endpoint, just the same functionality we have in Kraken, but now in Helix.
Being able to get information for an arbitrary set of emotes is useful, but knowing specifically what the currently authenticated has access to is useful for providing a better UI experience for things like emote intellisense, as we only want to show the emotes that user can actually use in chat. Otherwise all you could show to the user was the global emotes and the emotes for their channel.
The only other way I can think of to get this same effect would be to query for all the channels that user is subscribed, then make batch calls for all the emote sets for those channels.
GLOBALUSERSTATE provides the required information on server connect, as does USERSTATE on channel join
emote-sets A comma-separated list of emotes, belonging to one or more emote sets. This always contains at least 0. Get Chat Emoticons by Set gets a subset of emoticons.
Don’t need a “higher scoped above chat” token from the user to call the API when you can use emote-sets provided by TwitchChat itself to you.
I was stoked to read this update in the Twitch Developers Forum summary email just now. Thanks to everyone involved for your work on this, and pretty cool announcement re: Followers emotes!
Given the commitment to eventually migrate everything to EventSub, does that include enhancing it with additional EventSub event types when new API endpoints like these are released? It is great to be able to get the channel emotes from a given Twitch broadcaster, but that information could stale-date within hours of receipt.
To that end, are there plans to add additional EventSub event types to supplement these new API endpoints such as “Channel Emote Add” and “Channel Emote Remove”? Or given the new Library functionality rolling out, perhaps “Channel Emote Enable” and “Channel Emote Disable” might be more à propos?
We are actively adding subscription types to EventSub; we’ve added 14 so far this year for features like Raids, Polls, and Predictions. As we bring features to Helix we also look at whether it makes sense to bring them to EventSub, too.
We do not have immediate plans to add EventSub subscription types for Emotes. It is possible that these subscription types could happen in the future. If you have a cool use case, we’d love to hear about it in UserVoice!
Thanks @ecressey ! Yes I have been tracking with the subscription types the team has been adding to EventSub, and while some of them (Polls, Predictions) are less relevant to me personally, I appreciate all of the effort that has gone into extending EventSub!
I do believe I have a worthwhile use case for this; I will add it in UserVoice sometime before the end of the month. Cheers!
Hey, just wondering why emote objects returned from Get Emote Sets do not include tier of the emote, while Get Channel Emotes endpoint does. In my usecase I’d need to get the tier information for each emoteset I’m requesting, but that’s not possible. Could that tier field be added to the response of Get Emote Sets?
I’m speculating for the team, but I would assume there isn’t a particular reason that tier was excluded from Get Emote Sets. Feel free to create a UserVoice entry if you haven’t already to request tier in Get Emote Sets if the emote is a subscription type.
@jbulava Maybe this will be useful - I wanted to post it here that, so far, these are the IDs of emotesets I’ve encountered so far that have the same issue as described by @Rosuav: 472873131477339272488737509537206155564265402592920959610186276. 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 we’d need a way to query those in Helix. Many third-party chat clients use this functionality and it’s very important to us.