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.

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.

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.

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.

Channel points have the ability to reward loyal viewers with real-time influence on the stream. Sometimes such requests may be filtered, which should trigger a rejection (therefore refund).

Right now the only way to do this programmatically would be to use unsupported GQL APIs and risk the wrath of Twitch, or wrap the rewards queue in some way. This is the only blocker (technically speaking) for the workflow, as PubSub does expose enough information to respond to the redemptions automatically.

I've had a proof of concept on my stream which gets redemptions via PubSub, filters the submission for offensive content via an API, and changes some text elements on my stream layout automatically. It's been well-received by my (tiny) viewership but it would never really scale without these APIs.

Perhaps worth noting that there's a practical workaround that takes the bulk of the interaction out of Twitch: channel points rewards could be configured which are not queued, and are processed (via PubSub) automatically by a bot to turn into bot points - and then the bot points spent as prices on bot commands.