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

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)

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.