If I have an oAuth that represents a User, where the User is either

• the broadcaster the clip is of


• an editor of the channel that the clip is of


• the user is the owner of the clip

And I make a request for a Clip as documented: https://dev.twitch.tv/docs/api/reference#get-clips

(but with the bearer naturally)

The JSON Response should include the direct link to the MP4 or an ability to download the Clip.

This is off the back of the removal/deprecation of some undocumented API's that I was using to get the MP4 URL for automated download for creation of clip reels and similar.

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]

When creating a clip via the Create Clip API, it is VERY limited compared to the (not for public use) GraphQL interface. Requesting that the following enhancements be made to the Create Clip API so that 3rd party apps can leverage them:
1) Add ability to specify the clip start time (number of seconds from when the broadcast started). Reason: when deciding when to create a clip, apps may want to look back 10-15 seconds instead of generating the clip starting from when the API is called.
2) Add ability to specify the clip title. Reason: currently, the API defaults the clip title to the stream title, with no option to change it.

3) Add ability to specify the clip duration (max 60 secs). Reason: current API defaults to 30 seconds with no option to change it.
4) (nice to have) Ability to access raw media MP4 files once created.
5) (nice to have) Ability to specify the clip playback speed (default to 1.0)
6) (nice to have) Ability to specify the clip preview image offset in seconds (default to 0 - start of the clip)

The chat_moderator_actions topic in the PubSub documentation appears to only work with a broadcaster OAuth token. This prevents third-party modding tools that don't use some kind of centralized system from accessing information that is vital for effective modding (such as which mod performed an action, actions that aren't otherwise visible like unbans and viewing and approving messages filtered by AutoMod).

With a centralized system the broadcaster could provide a token somehow that the moderators don't need to have access to directly, however with purely clientside tools this is not feasible. I'm also not sure why moderators should not have access to that kind of information.

The moderator actions PubSub topic previously announced by Twitch Staff on the developer forums (https://discuss.dev.twitch.tv/t/in-line-broadcaster-chat-mod-logs/7281) does allow moderators to access this information. The announcement of the added "channel:moderate" scope requirement (https://discuss.dev.twitch.tv/t/upcoming-oauth-scope-requirements-for-pubsub/23203) gave me the impression that the old topic was now officially supported, so it's quite surprising and worrying that the topic added to the PubSub documentation has changed in a way that would break tools that many moderators have been using for years.

It would be very helpful to either add/clarify the old topic as officially supported as well, change the token requirements for the new topic or provide some other way to get the same information with a moderator's token.