Based on the current channel points API, a client may only access/update rewards for their own custom rewards. However, for some moderation tools, I believe managing custom rewards created by other clients and/or the Channel Owner's Dashboard would be beneficial.

Take for example a reward such as "Hydrate!", where, after 10 minutes you want this cleared from the reward queue if it hasn't been actioned already. To do this with the current API, a channel owner would have to first delete the existing "Hydrate!" reward and then recreate it using the script client. Repeating this for every reward to be controlled.

A potential way to implement this is a new Channel Points Reward dashboard called "Permissions" where channel owners can select which rewards can be controlled by which third-party clients. This dashboard would consist of a list of integrations where each integration has it's own list of rewards that it can control.

Even so, some integrations may wish to designate that they should have exclusive read/update/remove control over their own rewards (as in the current API) where they are created as "private" or "super-private" rewards. (private locks read/update/remove control, super-private would also lock enabled/disabled control)

For example:

Sound Alert can access the following rewards:
* Wowza (private)
* REEE (private)
* [Assign new reward]

Most rewards could then be added/removed to other integrations as the channel owner desires. Private rewards can still be assigned to other integrations to control their enabled state.

XYZ can access the following rewards:
* Silence Sound Alert for 10m (private)
* Twitch: Hydrate! (read/update/enable) [Edit] [Remove]
* Twitch: Name a world! (read/update/enable) [Edit] [Remove]
* Twitch: Text-to-speech (read/update/enable) [Edit] [Remove]
* Sound Alert: Wowza (enable) [Edit] [Remove]
* Sound Alert: REEE (enable) [Edit] [Remove]
* [Assign new reward]

If would be very useful for chat clients or chat overlays to be able to show live updates on these features. Currently they are only available for the broadcaster (redemptions) or not at all through websockets (polls/predictions).

Ideally this would be available for all users to receive, just like chat is (which allows more simple integration into all kinds of tools), but even just mods using third-party moderation tools would already benefit greatly from this.

I included all three of those features, since they all seem to follow the same idea of only allowing the broadcaster access to that information which is otherwise publicly available in chat. If you want me to separate the features into different posts I'd be happy to do it.

With the removal of the Follow Create endpoint.

A "non moderation bot" can no longer be automatically added to a channel.
The owner of the bot would have to "login" to the account and manually follow the channel(s) the bot joins.

A "non moderation" bot doesn't run moderation commands, so giving it "mod" wouldn't make sense. (Which would bypass the follow requirement)

Please provide a way to "authorise adding a bot to a channel" that will auto follow the bot to the channel. For this purpose

This could be similar to how Discord does bots, where to add a bot to a server, you need an oAuth flow, and then on compleition of that flow lets the bot in the server.

So in this example, I login as barrycarlyon I grant the bot access to my channel using scope "bot:allow" this auto follows that bot to my channel.

So the "follow" is initated from my website and the channel authenticating in.
And I've authenticated "my bot" to my clientID, and the target channel to my clientID.

This essentially sets it up, so that the destination channel triggers the follow.

The v5 endpoint contains the follower's account creation date, the new endpoint (https://dev.twitch.tv/docs/api/reference#get-users-follows) does not.

Knowing when a follower created their account is very useful to moderators monitoring recent follows to keep an eye on potentially problematic users (new account could mean a previously banned user returning) or to detect mass follows from bots (which often have a similar account creation date). Monitoring recent follows is especially useful in follow-only chat mode.

While it is possible to get the account creation date from the "Get Users" endpoint (https://dev.twitch.tv/docs/api/reference#get-users) and then merge it with the follower data, it would be nice if it were in the "Get Users Follows" endpoint as well, which would reduce the amount of API requests required.

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.

When viewers cheer, they use cheermotes and commonly emotes in their cheer messages. Unfortunately, the payload received from EventSub's channel.cheer callbacks only have the raw text as entered by the user, with no indiciation of which portions of that text are cheermotes nor emotes. Thus, I propose the following update to the callback payload, similar to the channel.subscription.message event, that passes along the data for both so that a consumer of EventSub can reconstruct the message:

{
    "subscription": {
        ...
    },
    "event": {
        ...
        "message": {
            "text": "Rah Rah Cheer! cheerwhal1 Cheer100 notACheer101 finite6ThrowBall",
            "cheermotes": [
                {
                    "begin": 16,
                    "end": 26,
                    "prefix": "cheerwhal"
                    "id": "1"
                },
                {
                    "begin": 27,
                    "end": 34,
                    "prefix": "Cheer"
                    "id": "100"
                }
            ],
            "emotes": [
                {
                    "begin": 48,
                    "end": 64,
                    "id": "emotesv2_4133039724974aa59589549eae677d03"
                }
            ]
        },
        ...
    }
}