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

The new helix endpoint to modify channel information ( https://dev.twitch.tv/docs/api/reference#modify-channel-information ) doesn't work with a user token from a user that has been added as an editor to the channel. This basicially shuts out any clientside tool used by editors where it's impractical for the broadcaster to directly authorize access. Editors should be trusted enough to be able to choose their own tools.

Allowing access to editors would especially make sense if this is intended as a replacement for the v5 endpoint ( https://dev.twitch.tv/docs/v5/reference/channels#update-channel ), which does allow editors to update the stream title and game. It would also work better together with the replace stream tags helix endpoint ( https://dev.twitch.tv/docs/api/reference#replace-stream-tags ), which also allows editors access.

I would appreciate it if this change could be made to allow tools to continue working when switching to helix.

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.

When a "gift bomb"

there is no way to gather all the gifts into one event.
Each gift in a bomb should have a ID to link it to the header event.

IRC sends a header saying "x is giving out y subs to the community"
But the USERNOTICE events, don't say they belong to that event.

Please provide a way to group the events, something as simple as a "parentid" in the child gifts subs, that'll link to a "childid" in the header event.

This header and extra ID's need to be provided on the PubSub event feed for subscriptions as well.

It might be beneficial to include on webhooks, but Helix doesn't only provide if it a given gift was part of a bomb or not.