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

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)

We third party dev's often build tools that assist with moderation actions/services for broadcasters.

We tell Moderators to enable 2FA, but we have no way to check it.

It would be useful to block Logins to our tool if 2FA is not enabled. But 2FA data is not surfaced in the API and there's no way to require a User to be 2FA during the login/oAuth loop.

I'd like to see the users endpoint(s) provide 2FA status.
I expect this to be behind the user read or openID scopes.

openID allows email verified. Why not 2fa status (for example)

Worth noting that Discords floats "mfa_enabled" in it's user API so we have precedent.

Some users have display names (the "user_name" property) that do not work for IRC or even in URLs. This requires an additional call to /helix/users with the ID to get the login which I find more crucial than the display name that is already included.

Here are two examples:

The user "riotgames" (ID 36029255) has a display name with a space. "twitch.tv/Riot Games" does not redirect to "twitch.tv/riotgames".

The user "hanryang1125" (ID 103825127) has a display name with Korean characters. "twitch.tv/풍월량" does not redirect to "twitch.tv/hanryang1125".

Neither of these display name would work for IRC, which goes for most display names since channel capitalization is not allowed. Simply lowercasing the display name may work for most channels but would fail in those example cases.