The old semi-unofficial API endpoint to allow/deny messages held by AutoMod used to cause an event in the PubSub "chat moderator actions" topic, which made sense because other moderators should be informed of this mod action. I think at some point it also happened when allowing/denying through the website.

Now allowing/denying through the website and the new endpoint (I think) does not provide this information to other mods. The only thing that is sometimes triggered is a channel terms action event, which is good, but it doesn't provide a direct connection to which message was affected (and it doesn't seem to always happen).

It would be quite useful if the "chat moderator actions" topic would send an event when a message is allowed/denied so other mods can see it.

Extend the Videos API via a "metadata" endpoint, that provides additional data about the video.

Including but not limited to

• Category changes during the video


• Offsets are relative to the source video that the video is from. So for a highlight it would report the video it was cut from and include where in the origin file the highlight is cut from.

For Example: https://api.twitch.tv/helix/videos/metadata?id=1234
Metadata would support up to 100 (or 50) id's at once like Get Videos

Returns examples

A video of type archive
{

"data": [

    {

        "id": "1234",

        "duration": 18000,

        "chapters": [

            {

                "offset": 0,

                "game_id": "200"

            },

            {

                "offset": 500,

                "game_id": "220"

            }

        ],

        parent: null

    }

]

}

A video of type highlight
{

"data": [

    {

        "id": "1235",

        "duration": 600,

        "chapters": [

            {

                "offset": 300,

                "game_id": "200"

            }

        ],

        "parent": {

            "offset": 200,

            "id": 4321

        }

    }

]

}

Use cases:

• if we present a highlight on a third party website, when the video is complete, we can present a easy way to go to the next Highlight in the series (where highlights are cut sequentially) or easily link to the original stream archive for continued watching.

This is an expansion of https://twitch.uservoice.com/forums/310213-developers/suggestions/38155990-return-tags-and-game-id-in-get-videos-in-helix

Please provide an API that provides

• what program is being watched


• What season/episode it is


• Episode/program title


• Cast information


• When started


• Link to the program on amazon (it's ASIN/whatever)

Information should be provide by broadcaster_id filter as a API
Sent out as a webhook (watchparty started, watchparty ended)
Provided as a PubSub event (started/ended/progress events?)

PubSub and webhook should also provide information about a Watch party about to start

The watch party player does a countdown to show start, so that should be replicatable.

People whom are not amazon prime members, or do not have that program available to them in their region will watch the program via another medium, and streamers are showing episode information and timers on screen. They are generating this manually.

It would be nice to do this automatically using an API from Twitch.

And the additional meta data will let us developers provide more tooling/information to the viewers. Such as looking up the program on other API's to get show/episode/cast information etc

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.

Add a occured_at timestamp that tells you when the content in the clip was actually streamed.

Clips API objects have a created_at timestamp which is when the user made the clip but this can be months or years off from when the content in a clip actually happened if a clip was made from a VOD which makes created_at useless for a lot of use cases.

Even for clips from livestreams this is an issue as users can cut clips from a 2 minute (90 secs?) window so the actual content of two clips with the exact same created_at timestamps can be completely different, which is surprisingly common in streams of fast paced games.

occured_at can sometimes be calculated manually with the VODs created_at timestamp (from /helix/video) + the clips vod_offset (from Kraken clips API, helix doesn't have vod_offset) as long as the vod is still alive. Once a vod expires (or is deleted for channels with permanent VODs) it's not possible to calculate that timestamp for a clip anymore.

Use cases:
* Displaying clips in any form of time based ordering or filtering
For example nobody wants to see a clip from two months ago when filtering for clips from the last week just because it was made three days ago from an old VOD
* Deduplicating clips with the same content
* Finding clips that happened right before or after a clip

Basically for almost anything you'd use created_at for occured_at would probably be better, having to do all of that with created_at gives a terrible user experience as the results will be off from what a user wants or expects.