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

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

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.

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.