701 results found

1. Expose HLS playback URL via helix

   I'm building a third-party Twitch client for iOS + Android and embedding player.twitch.tv in a WebView with the embedded JS method. One major problem is that this process is quite fragile on mobile. Playback
   works in the sense that audio plays and video advances but standing up a full chromium/safari instance on mobile is performance intensive and results in the view being quite taxing on the user’s device, in addition to not being the best developer experience:

   • WKWebView on iOS and Android System WebView both add memory and GPU cost on top of my application, rather than just using the lightweight AVPlayer (IOS) and ExoPlayer (Android) video player. We’re having to effectively shipping a mini-browser in the app to play one video.
   • Layout is expensive. Any animated resize of the WebView container (common in mobile: chat open/close, rotation, keyboard, bottom sheets etc.) can stall or detach the video compositor

   Because of this we’ve had to spend a lot of engineering time trying to get the webview to behave properly on both platforms, rather than focussing on other parts of the application and delaying our release of the application.

   What would actually be ideal and less of a frustration would be to have a Helix endpoint that returns a short-lived HLS URL for a live stream (and ideally VODs), so native apps can just use native video players instead of having to load a full chromium/safari embed.

   Example:

   GET /helix/streams/playback
   ?broadcaster_id={id}

   Response

   {
   "data": [{
   "broadcasterid": "123456",
   "streamid": "789",
   "playbackurl": "https://…/index.m3u8?token=…",
   "expiresat": "2026-06-07T20:30:00Z",
   "type": "live"
   }]
   }

   • 404 / offline when the broadcaster isn’t live, consistent with Get Streams.
   • Optional video_id param for VOD playback later
   • Clear docs on refresh cadence (when to re-fetch before the playback url expires)
   • Explicit rate limits

   This mirrors patterns that other video APIs use: fetch metadata, receive a stream URL and pass that to the player

   Constraints I’d expect from Twitch:

   • Requiring registered client ID + OAuth, same as the rest of Helix.
   • Geo / entitlement checks server-side.
   • Ads / subscriber only handled server-side in what URL is returned (or a clear error), not up to the client to implement ideally

   I'm building a third-party Twitch client for iOS + Android and embedding player.twitch.tv in a WebView with the embedded JS method. One major problem is that this process is quite fragile on mobile. Playback
   works in the sense that audio plays and video advances but standing up a full chromium/safari instance on mobile is performance intensive and results in the view being quite taxing on the user’s device, in addition to not being the best developer experience:

   • WKWebView on iOS and Android System WebView both add memory and GPU cost on top of my application, rather than just using the… more
   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Embeds  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Switch between Broadcaster/Viewer/Moderator/Anonymous

   Currently, testing extension UI across different user roles (Broadcaster, Moderator, Subscriber, Viewer, Anonymous) is a high-friction process that often requires coordinating with other users or managing multiple browser profiles. This inefficient feedback loop leads to avoidable production bugs.

   I propose an "Extension Simulation Mode" within the developer dashboard that allows us to:

   Role-Toggle: Instantly switch the Extension environment view between Broadcaster, Moderator, Viewer, and Anonymous roles.

   State Simulation: Toggle common state-dependent scenarios, such as subscription status or mobile/desktop viewport layouts.

   Impact: This would significantly improve developer velocity, reduce QA time, and increase the robustness of extensions by enabling comprehensive testing of permission-based UI logic.

   Currently, testing extension UI across different user roles (Broadcaster, Moderator, Subscriber, Viewer, Anonymous) is a high-friction process that often requires coordinating with other users or managing multiple browser profiles. This inefficient feedback loop leads to avoidable production bugs.

   I propose an "Extension Simulation Mode" within the developer dashboard that allows us to:

   Role-Toggle: Instantly switch the Extension environment view between Broadcaster, Moderator, Viewer, and Anonymous roles.

   State Simulation: Toggle common state-dependent scenarios, such as subscription status or mobile/desktop viewport layouts.

   Impact: This would significantly improve developer velocity, reduce QA time, and increase the robustness of extensions by enabling comprehensive testing… more

   4 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Extensions  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Hype Train Level Emotes Set

   There's currently no API to provide the list of emotes a hype train might provide. This could be done in multiple ways, both generally and in-context.
   For example:
   /helix/chat/emotes/set could add some constant emote set IDs for this purpose, such as hype-train-lv1, hype-train-lv4, etc...
   /helix/hypetrain/status could include the list of unlockable emotes for the current.level value.
   EventSub channel.hype_train.* could include the list of unlockable emotes for the level value.

   These would not require any new methods or events; just additional properties to the responses.

   4 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. Allow Create Stream Marker to accept an App Access Token

   Last month a slew of API endpoints were given beta App Access Token support - which is great!

   I was thinking the Create Stream Marker API would be a great candidate for also getting the App Access Token love.

   In my case it would be useful for us to offer a configuration so that when someone did something special in our extension, we could automatically add a stream marker.

   3 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. API and Dashboard Support for All Assigned Channel Roles

   There is already an endpoint that lets users see which channels they moderate. Please add a similar endpoint so users can retrieve all channels where they personally have assigned roles, such as VIP, Editor, Artist, Lead Moderator, or Channel Manager.

   Please also expand the “My Assigned Roles” dashboard page to include currently missing roles like VIP and Artist.

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

6. Add source_broadcaster_id to Get Chatters endpoint for Shared Chat sessions

   Problem:
   When a channel is in a Shared Chat session, the "Get Chatters" endpoint returns all chatters from all participating channels combined. There is no way to determine which chatters are native to which channel.

   Current behavior:
   The endpoint only returns userid and userlogin for each chatter, regardless of Shared Chat status.

   Requested feature:
   Add an optional sourcebroadcasterid field to the response (similar to how chat messages include source-room-id in EventSub). This field would indicate which channel the chatter is actually watching.

   This would bring the Get Chatters endpoint in line with the existing Shared Chat support in EventSub chat message events.

   Problem:
   When a channel is in a Shared Chat session, the "Get Chatters" endpoint returns all chatters from all participating channels combined. There is no way to determine which chatters are native to which channel.

   Current behavior:
   The endpoint only returns userid and userlogin for each chatter, regardless of Shared Chat status.

   Requested feature:
   Add an optional sourcebroadcasterid field to the response (similar to how chat messages include source-room-id in EventSub). This field would indicate which channel the chatter is actually watching.

   This would bring the Get Chatters endpoint in line with the existing Shared Chat… more

   4 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

7. "Remind Me" notification bell on scheduled events when their live.

   I’m building a Twitch app/extension that creates and manages scheduled events via the Helix Schedule API. We can create/read/update schedule segments, but there doesn’t appear to be a public API for Twitch’s native “Remind me” / bell notification for scheduled events.

   It would be nice to include the Remind Me button as an api call reminding users to call to action for certain events or when they go live.

   We could have a simple button that says "Remind me" on our app.

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

8. Get Ad Schedule incorrect response

   Since very recently, the "Get Ad Schedule" endpoint no longer returns RFC3339 formatted strings, but instead seems to return a number (probably time since epoch). The documentation clearly says "The UTC timestamp of the broadcaster’s next scheduled ad, in RFC3339 format."

   This is the case for:
   - nextadat
   - snoozerefreshat
   - lastadat

   Is the resonse a bug, or did the endpoint change?

   Thank you in advance.

   3 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

9. Get Suspicious User Status

   We have the ability to SET or REMOVE a user/viewers sus status but not the ability to check a users sus status (outside of real time in chat)

   This would be useful for extension developers to hold a sus users message for additionally moderation review before it goes thru to whatever outputs and extension has.

   3 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

10. Add Channel Filter to Get Moderated Channels

    There exists a Helix API which allows you to use a user access token with user:read:moderated_channels scope to call Get Moderated Channels, returning a list of paginated channels that the user is a moderator for. https://dev.twitch.tv/docs/api/reference/#get-moderated-channels

    I would like to be able to pass in a filter of channel ids (or broadcaster ids, the name is not precious to me) so that if I wanted to check a specific list of channels I could do so and potentially not have to iterate the cursor for results.

    I also think there should be a flag showing whether the user is Lead Moderator or just a normal one.

    There exists a Helix API which allows you to use a user access token with user:read:moderated_channels scope to call Get Moderated Channels, returning a list of paginated channels that the user is a moderator for. https://dev.twitch.tv/docs/api/reference/#get-moderated-channels

    I would like to be able to pass in a filter of channel ids (or broadcaster ids, the name is not precious to me) so that if I wanted to check a specific list of channels I could do so and potentially not have to iterate the cursor for results.

    I also think there should be a flag showing whether the user is Lead… more

    3 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  API  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

11. Documentation Issues and Open Sourcing

    Twitch offers a very large, widely-used API to a very large developer base, and unfortunately the documentation currently provided is severely lacking, inconsistent and falling behind standards of both accessibility and developer experience.

    I know this has been proposed some years ago, but I am going to recreate the voice as I believe I can add some extra points and reasoning.

    Issues with Accessibility:

    • Twitch only offers developers documentation in a fully white (#FFFFFF) background. While this is acceptable for most, this can be extremely difficult to navigate for people with certain eye, neurological and learning conditions. High contrast websites with white or close to white backgrounds have been shown to increase headaches, eye pain and sensitivity, reading and comprehension difficulties in people with these conditions.

    • The site offers very little contrast between important or differing sections of various parts of the documentation, for example all the tables, the highlights in the search and code-blocks.

    • There are no clear dividers between sections of the documentation, and parts which should be of lesser importance are more visible (bolder/higher contrast) than the sections diving them. E.g. https://dev.twitch.tv/docs/drops/ here under Test The Drop, it's not easily evident which section I am in as the H3 font weight is actually less than the H4, and the list.

    • Tables use simple whitespace indentation [which is often inconsistent and hard to read (especially given the above)], when trying to describe inner objects. See below: 1.

    Issues with usability:

    • There are no admonitions that clearly represent important notes, warnings etc that allow developers to clearly identify focus points.

    • 1. Instead of describing inner objects as separate objects we have to try and align indentation which can often lead to mistakes.

    • The tables that describe the response objects don't have indicators for nullable or optional fields, or if they do? they are an outlier, and are often wrong, or inconsistently described in the description column.

    • The tables are not dynamically sized and just squish and word-break a lot of the fields in bad places making it harder again to read especially when whitespace is used to indicate separate objects. (Check the flag reference here https://dev.twitch.tv/docs/cli/websocket-event-command/, even on a decently sized window.)

    • HTTP Methods ("GET", "POST") etc aren't clearly identifiable on endpoints.

    • Reference pages can be daunting to navigate, for example https://dev.twitch.tv/docs/eventsub/eventsub-reference/#events there are no inner href or visible references to any of these objects.

    • All the feedback buttons and status page are broken.

    Why Open Source?
    It's clear there is a need for better documentation. It's clear there is a need for developers that use the documentation to be able to express their ideas, issues and make pull-requests in a developer friendly/usable space (Like GitHub) and not community spaces like Discord or User Voices. Creating an Open Source space allows developers to identify changes and bugs as they are made and create relevant issues or pull-requests that can actually reference relevant code. It allows issues, commits, bugfixes etc to be easily tracked and searched. It takes brain power from you and distributes it to us, that's less money on coffee.

    Twitch offers a very large, widely-used API to a very large developer base, and unfortunately the documentation currently provided is severely lacking, inconsistent and falling behind standards of both accessibility and developer experience.

    I know this has been proposed some years ago, but I am going to recreate the voice as I believe I can add some extra points and reasoning.

    Issues with Accessibility:

    • Twitch only offers developers documentation in a fully white (#FFFFFF) background. While this is acceptable for most, this can be extremely difficult to navigate for people with certain eye, neurological and learning conditions. High contrast websites… more

    33 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Documentation  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. First Time Chatters

    Allow the channel.chat.message EventSub subscription to include if it is the first time the user has sent a message in the given channel.

    We can see this with IRC but not EventSub.

    I understand only broadcasters or moderators can normally see that directly from native twitch chat without extensions, so possibly a scope or moderator status would be required.

    It would just be nice to retain that information because it is useful for streamers who might use chatbots to respond to first time chatters with a welcome message. Also it is useful for moderation tools to see if a flood of first time chatters are 'raiding', and let moderators using 3rd party chat clients be able to see the new chatters as well.

    Allow the channel.chat.message EventSub subscription to include if it is the first time the user has sent a message in the given channel.

    We can see this with IRC but not EventSub.

    I understand only broadcasters or moderators can normally see that directly from native twitch chat without extensions, so possibly a scope or moderator status would be required.

    It would just be nice to retain that information because it is useful for streamers who might use chatbots to respond to first time chatters with a welcome message. Also it is useful for moderation tools to see if a flood… more

    166 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    19 comments  ·  EventSub  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

13. Drops & rewards

    Drops & Rewards - Inventory - In Progress:
    The ability to hide the drops that are finished, the 'This reward is no longer available' ones.
    Some remain in view days after their finish date.

    5 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Drops  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

14. Extend Clips API to provide the MP4 url for overlay automation

    Extend Clips API to provide the MP4 url so clips can be played in in broadcast overlays of raiding streamers and friends of a channel.

    With Content Classification Labels so that they can be filtered out and not allowing unwanted continent from another streamer to be broadcast

    The current <Iframe> Is unsuited for this as most broadcast software can not use an <Iframe> as a media source and the browser sources are laggy and unreliable at bn

    When I make a request for a Clip as documented: https://dev.twitch.tv/docs/api/reference#get-clips

    The JSON Response should include the direct link to the MP4 or an ability to download the Clip and send the Content Classification Labels.

    This is off the back of the removal/deprecation of some undocumented API's that I was using to get the MP4 URL for overlays and similar systems for download or creation of clip reels.

    Extend Clips API to provide the MP4 url so clips can be played in in broadcast overlays of raiding streamers and friends of a channel.

    With Content Classification Labels so that they can be filtered out and not allowing unwanted continent from another streamer to be broadcast

    The current <Iframe> Is unsuited for this as most broadcast software can not use an <Iframe> as a media source and the browser sources are laggy and unreliable at bn

    When I make a request for a Clip as documented: https://dev.twitch.tv/docs/api/reference#get-clips

    The JSON Response should include the direct link to the MP4 or… more

    23 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    4 comments  ·  API  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

15. Add Message Filter to Channel Chat Message Conditions

    Most bot functionality is behind trigger characters, with "!" being the most popular. For such bots, receiving a webhook message for every message in chat is an unnecessary number of requests. I suggest a simple prefix comparison or regular-expression based "message_filter" condition to allow limiting channel.chat.message subscriptions, reducing network overhead and load at the cost of a single comparison.

    4 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  EventSub  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

16. Add a bitflag to channel.chat.message for chatters (chatter_flag)

    In several discussions across Twitch-related Discord servers, it has been highlighted that the channel.chat.message payload currently lacks specific chatter status fields, such as ismoderator or isvip. Given the already substantial size of the payload, adding individual key-field pairs for each potential status could unnecessarily increase both bandwidth usage and processing time.

    To address this, I propose the introduction of a single key: chatter_flags. This field would utilize a bit flag to represent multiple statuses within a single integer value. This approach not only minimizes data transmission but also simplifies the process of updating and checking user statuses—especially as new ntatuses are introduced. Checking badges is also not reliable due to them having the option to be hidden.

    From the perspective of library maintainers, this solution would significantly streamline integration. Most libraries serve primarily as wrappers, with notable exceptions, and often recommend fetching moderator, follower, and VIP statuses through the HELIX API. They then suggest maintaining these details via EventSub, which isn't always practical for end users who want simple safeguards. The proposed chatter_flags would provide a more efficient and manageable method for handling user statuses directly through the message payload.

    This change would be particularly beneficial for developers by reducing the complexity and overhead associated with managing multiple API calls and data synchronization, thereby allowing for more focused and efficient application development.

    Example implementation:

    Follower: 1st bit (1 << 0) = 1
    VIP: 2nd bit (1 << 1) = 2
    Moderator: 3rd bit (1 << 2) = 4
    Subscriber: 4th bit (1 << 3) = 8
    Turbo: 5th bit (1 << 4) = 16

    User is only a Moderator: chatterflags = 4
    Combined Moderator and Subscriber flags: chatterflags = 4 + 8 = 12
    Combined Follower, Moderator and Subscriber flags = 1 + 4 + 8 = 13
    Combined Follower and VIP flags: chatterflags = 1 + 2 = 3
    Combined Subscriber and VIP flags: chatterflags = 8 + 2 = 10

    Developers can then simply check the bits of the int to get and instant understanding of the chatter's status to perform or prevent actions. This could even be a V2 endpoint in parallel if people do not wish to receive the information.

    In several discussions across Twitch-related Discord servers, it has been highlighted that the channel.chat.message payload currently lacks specific chatter status fields, such as ismoderator or isvip. Given the already substantial size of the payload, adding individual key-field pairs for each potential status could unnecessarily increase both bandwidth usage and processing time.

    To address this, I propose the introduction of a single key: chatter_flags. This field would utilize a bit flag to represent multiple statuses within a single integer value. This approach not only minimizes data transmission but also simplifies the process of updating and checking user statuses—especially as new ntatuses… more

    30 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  EventSub  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

17. Stream together participants in /helix/streams

    It would be nice if /helix/streams had an array of the channel id's of the channels its streaming with. One use case for this would up updating the automated live message in Discord if and with who they're streaming together in addition to updating the title/category

    4 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  API  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

18. Ability to Select Playback Quality

    My internet is not fast. It would be nice if I can downgrade playback/streaming to a lower quality so that I don't experience video studder.

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Embeds  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

19. Trigger channel.bits.use on extension bits usage

    Currently the channel.bits.use event doesn't seem to grab extension bits use - for example, Tangia.

    This is something that is already visible in the streamer (and moderator) activity feed, and it would be very useful to have on this eventsub trigger as well.

    6 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  EventSub  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. Improving Campaign Engagement Through Daily Watch Limits

    Right now, a campaign that requires 15 hours can just be binge-watched on the first day. I’d love to have the option to limit daily hours to encourage players to participate across multiple days instead.

    5 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Drops  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating