Announcing API endpoints for Twitch emotes

A new set of Twitch API endpoints are now available for retrieving Twitch emotes, previously only available in the legacy v5 version of the API.

Please feel free to provide comments or questions below.

Get Channel Emotes

Gets all custom emotes for a specific Twitch channel including subscriber emotes, Bits tier emotes, and follower emotes. Custom channel emotes are custom emoticons that viewers may use in Twitch chat once they are subscribed to, cheered in, or followed the channel that owns the emotes.

Get Global Emotes

Gets all global emotes. Global emotes are Twitch-specific emoticons that every user can use in Twitch chat.

Get Emote Sets

Gets all Twitch emotes for one or more specific emote sets.


The Get Channel Emotes endpoint is bugged - emote_set_id returns emote ID instead of actual emoteset’s ID. Related GitHub issue

1 Like

Appreciate the mention! The correction is already being reviewed and should be in production soon.

Confirming the emote_set_id correction is now in production.

1 Like

That was fast, thanks for such a quick fix!

On another note though, with those new emote endpoints being added, me and other developers were wondering if we could see the reflection of Kraken’s Get User Emotes in Helix any time soon.
What you’ve just announced is very helpful, however it’s still impossible to fully migrate from Kraken because of need to fetch all the emotes that are available to user.


You should open a uservoice if one doesn’t already exist.

Feature/migration requests below on the UV

I agree with this. The ability to get all emotes was one of the cooler, though likely less used, endpoints of v5. I used it myself to see how many people had Pog Emotes at one point, and there is at least one site that uses it to catalog the emotes.

Given the Emote Sets endpoint, it might be a good idea to make an endpoint to get all emote set ids, (not including the emotes themselves). Potentially including some metadata about the set, such as emote count and last updated date so that the data can be cached.

Thank you for providing this! Finally, bit-unlock emotes show up. Not sure if I’ve missed something though; how do we find out which emote set IDs exist?

Not that thing that was ever possible before.
You could sort of extract them from the old v5 get all emoticons.
But you couldn’t tell what emoteSetID was for which channel

It’s primary use case was (the set ID) for “caching emotes from emotesetID’s returned from UserNotice in chat”

Then you need a uservoice

Though I’m not sure Twitch wants to support this use case (random stats to see who has pog emotes)

Not sure which UserNotices you mean as I don’t recall them showing up with set IDs, but if it’s a caching thing for emote IDs that have been seen, then that makes sense.

I’ve tried this with a few, but I can’t seem to query (for instance) the set of hype train emotes (477339272), so I’m probably doing somethign wrong.

Sorry I meant GLOBALUSERSTATE having rechecked the docs.
And the tag emote-sets

lets chat clients know what “emote sets” by “emote set ID” that the chat user has access to.

@badge-info=subscriber/8;badges=subscriber/6;color=#0D4200;display-name=dallas;emote-sets=0,33,50,237,793,2126,3517,4578,5569,9400,10337,12239;turbo=0;user-id=1337;user-type=admin GLOBALUSERSTATE

Entirly possible that the HypeTrain moved on to the next set of Emotes since they change periodically and it’s no longer valid.

Thanks. An issue I noticed is that when I unlock an emote using Channel Points, a new emoteset appears in the emote-sets tag of the USERSTATE command in IRC, however requesting that emoteset using<emoteset> returns {"data":[]}.

Not sure how emotesets work in these cases, it seemed like unlocking more emotes with Channel Points didn’t add more emotesets. The emote-sets tag also used to be unreliable for some types of “special” emotes (seeminly randomly alternating between different emote sets), but that doesn’t seem to happen anymore (although I haven’t checked if it contains all emotes I have access to, besides the Channel Points issue).

Either way, if a “get all emotes a user has access to” endpoint would exist, I would prefer to use that anyway, since that would be simpler than potentially doing several requests based on the emote-sets tag (if a user has more than 25 sets). Currently I’m using the Kraken endpoint.

Or since

  • hypetrain
  • channel points emotes

Don’t work setID’s reported as “not working”

Looks like “get by emote set ID” only does

G ets all custom emotes for a specific Twitch channel including subscriber emotes, Bits tier emotes, and follower emotes.

I anticipate “Get by Emote Set ID” (currently) only does the same groups as " Get Channel Emotes"

Ah yep, that one. Thanks. I had a different way of seeing some set IDs, but it’s clearly the same IDs, so it’s all good.

Definitely possible, but I think your comment in the next post is more accurate: this API is limited to channel emotes. Would be nice to have access to ALL emote sets this way.

@zneix @tduva
We do not plan to offer an endpoint to retrieve the emotes that a user has access to as this exposes subscription information that should be considered private.

Barry mentioned emote set IDs in IRC, but just to add to that, they are also included in the data returned for Get Channel Emotes and Get Global Emotes, so you can use these values to make further calls to Get Emote Sets. The API does not provide a resource that lists all existing emote set IDs if that’s the use case you are asking for though.

And I’ll ask the API team about Hype Train emotes. Can you provide an example request and response where you are seeing the emote set ID for Hype Train emotes is 477339272? If you do not want to post here, please feel free to DM the information. Thanks.

1 Like

Yes, that would be an excellent tool - a way to list emote set IDs for Twitch unlockable emote sets (the hype train sets, “2020 Hindsight”, the 2FA ones, Turbo, etc). The emotes in them are public; whether or not someone has them might be private.

It’s pretty straight-forward. returns {"data": []} . I was using a generic login token that I use for “non-authenticated” API calls, which is associated with my Twitch account named Rosuav; if it’d make a difference to use a different token or an app token, I would be very surprised.

There may be a wrinkle with some of these emote sets in that they are not unlocked as a single block. Hype train emotes are a great example of this - they’re logically a single block, but you unlock them one by one. I’m not sure whether that means they’re a single emote_set_id or thirty individual ones. TBH I’d be okay with either, but if they’re thirty separate ones, then it would be incredibly helpful to have an emote set grouping indicator that says “hey, these thirty should logically be shown together” (think about how the on-platform emote picker groups them all).

That would need to be an authenticated endpoint, which shouldn’t be a problem. There’s currently a v5 endpoint that gives this, and it needs the user_subscriptions scope. A Helix version of the same endpoint (requiring whatever the Helix equivalent of that scope is) could provide the equivalent information, with the addition of all the v2 emotes.


I couldn’t find a UserVoice for this (I thought one existed, but maybe I was thinking of a similar one), so I added one: Get the authenticated user's emotes (equivalent to existing Kraken endpoint) – Twitch UserVoice

Using the GET endpoint, bitstier type emotes seem to not return a tier, only a blank string. Is this intentional or is this supposed to return the amount of bits required to unlock said bit emote?

Example from the response of the following request GET

The docs state

If the emote_type is "subscriptions" , this indicates the subscriber tier at which the emote is unlocked. Set to an empty string otherwise.

So no.