I would like to be able to react to a user disconnecting my application from their account without having to constantly poll with the user's token to ensure that it is still valid. If I were to constantly poll for all users that have used FrankerFaceZ's website, I would be making thousands of requests per minute. My servers don't need the unnecessary load. Your servers don't. There is a better way.

For this I request implementation of a revocation webhook, similar to those used by GitHub (ref1), Facebook (ref2), Slack (ref3), Discord (ref4), etc.

To clarify, I don't want a webhook as they have been used previously with Twitch's API. I want to be able to use the admin panel to associate a URL with my OAuth app that is hit when a user disconnects from my app. This represents an event that I would want to know about in perpetuity for the lifetime of my application and having to constantly re-subscribe would just waste everyone's time. If you do choose to implement this as other webhooks have been implemented, please do NOT require us to subscribe to each individual user. The idea is that we want to know about any authorized users disconnecting.

For example, if I entered the URL " https://my-site.example/webhooks/disconnect " then I would expect Twitch to POST to that URL when a user disconnects with a JSON payload including, at a minimum, the Twitch user ID so that we can identify the user and perform any relevant logic to deactivate their account in our system.

This is similar to the existing topic "Extension webhooks for streamer actions", but I believe that OAuth connections and adding an extension to a channel are sufficiently different topics to warrant posting this again. I also want to make it clear that this should 1: Not be a standard webhook that requires us to constantly resubscribe for every user using our app and 2: This should not be overly tied to extensions and should be for OAuth connections.

Thank you for your consideration.

Ref 1: https://developer.github.com/v3/activity/events/types/#githubappauthorizationevent
Ref 2: https://developers.facebook.com/docs/graph-api/webhooks/reference/permissions/
Ref 3: https://api.slack.com/events/app_uninstalled
Ref 4: https://discordapp.com/developers/docs/topics/gateway#guild-delete

As well discussed and pointed out in the announcement thread (ref 1). It makes no sense, The matching client id can be grabbed from the oauth url as ClientID's are public right? Atl east your own documentation says so (ref 2) And if not grabbed from the url they are publicly displayed with matching user data and scopes when sending a request to https://id.twitch.tv/oauth2/validate which can be accessed with just a OAuth token. This change is gonna reach nothing but us having to make our code more complicated by having to consistently keep track of client id's that where used for a token or create extra unnecessary traffic on the oauth2 validate endpoint to get the client id used while authenticating back. For more reasons why not to do this please read the posts in the announcement thread (ref 1). Please do us all a favor and just cancel these plans. Thanks

References:

1: https://discuss.dev.twitch.tv/t/requiring-oauth-for-helix-twitch-api-endpoints/23916
2: https://dev.twitch.tv/docs/authentication#registration

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.

For the purposes of GDPR it would be useful to have the following webhooks:

• When a Streamer installs an extension


• When a streamer activates an extension


• When a streamer deactivates an extension


• When a streamer uninstalls an extension.

The most important one is the uninstall, it allows us the third party to be notified of an uninstalled.

The Shopify platform has this with the rule that a third party should, automatically delete all Store (and that stores customer data) 30 days after that hook triggers.

We need/should do the same, delete any broadcaster, or broadcaster viewer (and subscribers) data 30 days after the uninstall. (The 30 days allow for the broadcaster to reinstall the extension and avoid the caster having to re-setup the extension, when talking about any configuration, and hence the need for the install hook to go hand in hand)

Activate/deactivate are useful for the purpose of turning on/off any backend services related to the extension, couple that with https://twitch.uservoice.com/forums/310213-developers/suggestions/37563622-live-activated-channels-w-extension-webhook for video extensions to improve accuracy of whose live and who needs backend service support.

Like Bits transaction, it would be great to allow Channel points to be accessible from an extension.

The idea is to not expose channel points to the extension and work the same way Bits transactions are.

This would also need the addition of channelPointSku or allow sku product to have a bits value and/or a channel Point value.

• User click on a button


• Extension fires window.Twitch.ext.points.usePoints(pointsSku)


• User validate transaction


• (if user complete transaction )OnTransactionCompleted callback is fired with receipt containing channelPoint as the currency used


• (if user cancel or don't have the channel Points) onTransactionCanceled is called

To complete it, adding a filter on the endpoint GET helix/extensions/transactions would allow developers to only get Bits transaction, channel points transaction or both.

Channel points in extensions would help people to discover features, interact with extensions more and at the same time, give a way to regulate the interaction by using channel points instead of free actions.

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)

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.

Hey. I know that people are requesting API for Channel Points. But I came up with better and easier idea.

When streamer creates new reward in dashboard, there should be option to "run a link" in background after reward is redeemed. This type of button will trigger bot with GET-request and bot will run specific action.

Why I think this approach is better than API:
1. No API on Twitch side, obviosly.
2. Bots won't be abble to control Channel Points directly.
3. This will work with any bot who will support this kind of triggers.
4. Easier to use and understand for regular users. Bots developers could design this as "to run this action paste this link in your reward". This sounds pretty easy.
5. Gonna be pretty easy to exclude failed requests for Twitch. You just check if requested link returned: {response: success} or something like that. If it returned something like {error: "Requested video have not enough views."} then you just show this error to viewer and do not take his Channel Points.

Possabilities here are endless. Viewers will be able to request songs with Channel Points, run some sounds and animations on stream, play mini-games, change color of lights in streamer's room, etc.