It would be useful if the following values could be added to each emote:

• Channel Name (e.g. "owner name") - Obviously the name can be retrieved from the "owner id" by doing another API request, but it would be nicer to require fewer API requests
• Tier - The "Get Channel Emotes" endpoint already contains a "tier" value, it would be nice if this one would also have it

Additionally, not all emote sets appear to be supported by the endpoint. For example the following emote sets (from the "emote-sets" tag and also valid emote sets in the v5 "Get User Emotes" endpoint response) only return an empty result:

https://api.twitch.tv/helix/chat/emotes/set?emote_set_id=472873131
https://api.twitch.tv/helix/chat/emotes/set?emote_set_id=564265402
https://api.twitch.tv/helix/chat/emotes/set?emote_set_id=592920959
https://api.twitch.tv/helix/chat/emotes/set?emote_set_id=610186276
https://api.twitch.tv/helix/chat/emotes/set?emote_set_id=488737509
https://api.twitch.tv/helix/chat/emotes/set?emote_set_id=537206155

Not sure if this is a bug or intentional limitation, but it would be useful if it would support all valid emote sets.

The addition of the Emote Library that is coming soon is a fantastic addition, this is great for solving the issue of disparity between partners and affiliates on emote variety, without undermining the parner program and is a fantastic compromise.

I would like to suggest the addition to the Twitch API to allow for enabling and disabling of active emotes from the Emote library via a privlaged API call from a token with sufficient privlages through oAUTH.

An example of the proposed usecase would be 4 API calls:
-Activate Emote [Params: Emote ID, (Optional: Emote Slot)]
-Deactivate Emote by ID [Params: Emote ID]
-Deactivate Emote by Slot [Params: Emote Slot]
-Replace Emote by ID [Params: Emote ID to Find in active emotes, Emote ID to replace with if Param 1 ID is found in active emotes]

• Activate Emote would add an emote from the emote library by specified ID to the first free slot on the channel's active emotes, or if specified would overwrite an emote in the specified slot.

• Deactivate Emote by ID would remove an emote from the active emotes by specified ID if present in any current slot, if emote ID not found, would do nothing or respond with an Error code.

• Deactivate Emote by Slot would deactivate any active emote found in a specified active emote slot, If slot is already clear, would do nothing or respond with an Error code.

• Replace by Emote ID would search active emotes in slots for a specified emote ID, if found the slot containing the found result would be cleared and then a emote from the emote library specified by ID would be activated to the specified slot.

Programatic access to these functions would allow for great viewer interaction by the creation of immersive experiences allowing viewers to use channel points or other events monitored for via IRC or the pubsub API, to trigger changes to active emotes without disrupting the viewing experience by requiring human intervention by the streamer or another user with privlages to swap emotes.
This would also facilitate the ability for channels that play a few different games or perhaps playthroughs such as variety streams to increase their appeal by creating emotes that are themed around current games or ongoing themed streams, which can then be automatically swapped in and out via the twitch API.

This is an amazing addition you've come up with here for the emote library and I would love to see this included programatically in the API for Follower Emotes, Subscriber Emotes and Bit Emotes ideally, but at the very least, subscriber emotes.

Brief description

https://dev.twitch.tv/docs/authentication/getting-tokens-oauth

When you get a token, it returns token_type as bearer

If you take this value as is and call helix endpoints it doesn't work as helix only accepts Bearer

How to reproduce

Generate a token
Construct a header using the returned data by concatenating elements from the returned JSON
`Authorization: ' . tokentype . ' ' . accesstoken

Call a helix endpoint
Get a 401
Expected behavior

Twitch accepts Bearer and bearer as valid

or

returns Bearer as the token type when fetching a token.

Additional context or questions

I'm not sure what the correct solutions is after a brief perusal of the RFC's

Request origin:

https://github.com/twitchdev/issues/issues/219

The new API endpoint 'Get User Follows'
https://dev.twitch.tv/docs/v5/reference/users#get-user-follows

Could include more data than what is currently provided.
The legacy endpoint alternative offers a lot more but not all of this info is required by default.
https://dev.twitch.tv/docs/api/reference#get-users-follows

My suggestion would be to at least provide the 'notifications' as well as the 'logo' info. To keep the requests at an optimal size by default, extra request parameters can be given such as:

?showLogo=true&showNotifications=true
(which can default to false when not present)

or

?verbose=true
(which will provide an equivalent response to the legacy variant)

The new endpoint should also only show this extra info as long as the token provided belongs to the given 'to_id'. Otherwise everyone can see who has the notifications activated for which streamer

The new endpoint only allows the broadcaster to run commercials: https://dev.twitch.tv/docs/api/reference#start-commercial

The old endpoint also allowed users with the editor role to run commercials: https://dev.twitch.tv/docs/v5/reference/channels#start-channel-commercial

I believe it is of value to allow access to editors as they used to. Editors should be trusted enough to choose their own tools to support the broadcaster, as has already been the case.

Plus, if an editor's token can be used the editor's name will appear in the Activity Log on the Dashboard, rather than the broadcaster's name (assuming some sort of webpanel or bot has to be used, that the broadcaster has granted access), which may lead to confusion. This seems unavoidable for some use-cases, however where possible I would very much prefer the simpler option of using the access token of whoever actually triggered the action.