# EventSub WebSockets are now available in open beta **URL:** \ **Category:** Announcements\ **Created:** [November 1, 2022, 6:30pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639 "2022-11-01T18:30:03Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![jbulava](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/jbulava/32/6777_2.png) [@jbulava](https://discuss.dev.twitch.com/u/jbulava)\ **Post date:** [November 1, 2022, 6:30pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/1 "2022-11-01T18:30:03Z")
EventSub is our interface that defines the real-time Twitch events accessible to third-party developers such as hype trains, when a creator goes live, or when a viewer subscribes to a channel. Providing this information empowers creator tools, games, and other applications to build interactive experiences and provide those magic moments in live broadcasting that are compelling and meaningful. When we launched EventSub, we started with Webhooks as our first supported transport protocol for receiving event information and we promised more protocols in the future to unlock further use cases. In January, we announced the closed beta for WebSockets in EventSub. We’ve been gathering feedback and improving the product since then and today it is available for everyone in open beta. ## Why WebSockets? Developers have made it clear that there are certain scenarios where Webhooks aren’t the best solution. Many applications run on computers or devices that the developer does not have control of, for example, a browser application to manage Channel Points rewards or a game that triggers a boss fight when there’s a Hype Train. These applications need to create subscriptions and receive notifications from EventSub, but don’t always have a server available that can receive notifications over Webhooks. Ultimately, we think adding WebSockets to EventSub means you’ll be able to build applications that power new ways for creators and viewers to strengthen their communities on Twitch. ## How do I get started? The [EventSub documentation for WebSockets](https://dev.twitch.tv/docs/eventsub) is now available on the Twitch developer website. There you’ll find a new guide for WebSockets and an updated API reference to support the new protocol. The [Twitch CLI documentation](https://dev.twitch.tv/docs/cli) has also been updated today to support reconnect testing for EventSub WebSockets. Additional CLI functionality is being considered as well for a future release. ## Can I use this in a production environment? Great question! We are updating our “beta” classification on the [Product Lifecycle](https://dev.twitch.tv/docs/product-lifecycle) page today to indicate that, yes, you can now use Twitch developer products that are in open beta in a production environment. However, as also mentioned, it comes with the understanding that we may make breaking updates during the open beta period, which could negatively impact your implementation. While we do our best to give developers notice of changes during an open beta, it is not always a guarantee based on the type of changes necessary. ## Where can I provide feedback? As you start testing WebSockets, we would love to hear your comments, questions, and feedback. To provide suggestions, please use the [EventSub UserVoice forum](https://twitch.uservoice.com/forums/310213-developers?category_id=396520). You can use the [Twitch Developer Forums](https://discuss.dev.twitch.com) or the [TwitchDev Discord server](https://link.twitch.tv/devchat) for questions and discussing WebSockets with other members of the community. Many of the new subscription types we built this year were suggestions you asked for in UserVoice. Thank you for providing your feedback and helping us continue to improve EventSub. ## How long will EventSub WebSockets be available in open beta? We don’t have a firm end date to announce for the open beta at this time. At a minimum, we expect the open beta to run for several months as we continue to develop the product and as we incorporate your feedback from the open beta. ---
**Author:** ![Marenthyu](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/marenthyu/32/530_2.png) [@Marenthyu](https://discuss.dev.twitch.com/u/Marenthyu)\ **Post date:** [November 1, 2022, 7:32pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/2 "2022-11-01T19:32:34Z")
[![](https://i.gifer.com/ZQB.gif) ](https://i.gifer.com/ZQB.gif) ---
**Author:** ![sogehige](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/sogehige/32/4661_2.png) [@sogehige](https://discuss.dev.twitch.com/u/sogehige)\ **Post date:** [November 1, 2022, 7:36pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/3 "2022-11-01T19:36:48Z")
Nice! ---
**Author:** ![JoostSchuur](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/joostschuur/32/13476_2.png) [@JoostSchuur](https://discuss.dev.twitch.com/u/JoostSchuur)\ **Post date:** [November 1, 2022, 10:46pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/4 "2022-11-01T22:46:14Z")
Question on the [subscription limits](https://dev.twitch.tv/docs/eventsub/manage-subscriptions#subscription-limits): Does the 3 web sockets/100 ‘enabled subscriptions’ limit imply that you can only have 300 active subscriptions? So if I wanted to subscribe to `stream.online` and `stream.offline` events for a number of channels, would that mean I could only monitor 150 of them (3 \* 100 / 2)? I’m not sure what an ‘enabled subscription’ is and how this relates to `max_total_costs`, since one code snippet shows a value of 10000 for that. ---
**Author:** ![BarryCarlyon](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/barrycarlyon/32/253_2.png) [@BarryCarlyon](https://discuss.dev.twitch.com/u/BarryCarlyon)\ **Post date:** [November 1, 2022, 10:51pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/5 "2022-11-01T22:51:21Z")
> [@JoostSchuur](#): > > I’m not sure what an ‘enabled subscription’ is and how this relates to `max_total_costs`, since one code snippet shows a value of 10000 for that A single websocket can have 10 cost 1 subscriptions on it. So you will run into that limit _first_ > [@JoostSchuur](#): > > So if I wanted to subscribe to `stream.online` and `stream.offline` events for a number of channels, would that mean I could only monitor 150 of them (3 \* 100 / 2)? This sounds more like you want the regular/webhooks transport than the sockets transport for this use case. And without auth you’d only be able to monitor 3 sockets 10 cost 1 topics per socket 2 topics (stream up/down) (3\*30 / 2) so 15 channels… ---
**Author:** ![zibbp](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/zibbp/32/20905_2.png) [@zibbp](https://discuss.dev.twitch.com/u/zibbp)\ **Post date:** [November 3, 2022, 3:30pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/6 "2022-11-03T15:30:32Z")
Hi, Is there any plan to support “app access” tokens rather than “user access” token for subscribing to Websocket events? The webhook events used app access tokens but I cannot use app tokens with webhooks. Is there a reason why this is not allowed? Thanks. ---
**Author:** ![BarryCarlyon](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/barrycarlyon/32/253_2.png) [@BarryCarlyon](https://discuss.dev.twitch.com/u/BarryCarlyon)\ **Post date:** [November 3, 2022, 4:27pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/7 "2022-11-03T16:27:46Z")
> [@zibbp](#): > > . Is there a reason why this is not allowed? I would posultate this is to prevent you trying to use an app access token in a frontend application, where you would then leak the app access token. So in front end apps where a socket makes sense you would use the user token as you can easily obtain a user token from the user. Sockets _feel like_ they are not intended for use cases where you have an app access token as you would be using the webhook transport instead as app access is for “server to server” communication. ---
**Author:** ![zibbp](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/zibbp/32/20905_2.png) [@zibbp](https://discuss.dev.twitch.com/u/zibbp)\ **Post date:** [November 3, 2022, 5:47pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/8 "2022-11-03T17:47:23Z")
Makes sense. I was hoping Websockets could use app tokens because to use Webhooks you need a publicly accessible endpoint for callbacks, which I prefer not to do when developing selfhosted applications. ---
**Author:** ![BarryCarlyon](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/barrycarlyon/32/253_2.png) [@BarryCarlyon](https://discuss.dev.twitch.com/u/BarryCarlyon)\ **Post date:** [November 3, 2022, 5:48pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/9 "2022-11-03T17:48:19Z")
> [@zibbp](#): > > which I prefer not to do when developing selfhosted applications. if self hosted then _logically_ it’s self hosted by the user whose events you need to consume, so you can easily get the users token to work with. ---
**Author:** ![zibbp](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/zibbp/32/20905_2.png) [@zibbp](https://discuss.dev.twitch.com/u/zibbp)\ **Post date:** [November 3, 2022, 6:10pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/10 "2022-11-03T18:10:53Z")
For sure. Was hoping to re-use an app token but the user token shouldn’t be too big of an issue to implement as well. ---
**Author:** ![BarryCarlyon](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/barrycarlyon/32/253_2.png) [@BarryCarlyon](https://discuss.dev.twitch.com/u/BarryCarlyon)\ **Post date:** [November 3, 2022, 6:13pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/11 "2022-11-03T18:13:25Z")
well unless it’s your _own_ app for _yourself_ then you shouldn’t be using app access. As those should be kept private to the developer and not leaked ot other users But yeah user token straight forward enough (and means they work great as github examples #notAnAd - [Poll Tool | Twitch API Example](https://barrycarlyon.github.io/twitch_misc/examples/poll_tool/) and others… ) ---
**Author:** ![tduva](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/tduva/32/392_2.png) [@tduva](https://discuss.dev.twitch.com/u/tduva)\ **Post date:** [November 13, 2022, 5:38am UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/12 "2022-11-13T05:38:47Z")
> [@BarryCarlyon](#): > > 3 sockets > 10 cost 1 topics per socket > 2 topics (stream up/down) Is that really how it works? The [documentation](https://dev.twitch.tv/docs/eventsub/manage-subscriptions#subscription-limits) under WebSocket Limits says: > The `max_total_cost` is 10 across all subscriptions. That sounds like it’s not per socket, but overall. And from testing when I open two sockets the total\_cost in the “Create EventSub Subscription” response seems to increase independent of the websocket session\_id (with the max always being 10). So in the above example with two 2x1 cost topics you could monitor 5 channels via websocket (assuming one token of one user is used). Seems quite limited and means that I will probably only subscribe to a single topic so I can at least get a few channels in (and keep relying on polling for what would otherwise be useful as an event like stream online/offline). ---
**Author:** ![BarryCarlyon](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/barrycarlyon/32/253_2.png) [@BarryCarlyon](https://discuss.dev.twitch.com/u/BarryCarlyon)\ **Post date:** [November 13, 2022, 11:48am UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/13 "2022-11-13T11:48:50Z")
> [@tduva](#): > > That sounds like it’s not per socket, but overall. And from testing when I open two sockets the total\_cost in the “Create EventSub Subscription” response seems to increase independent of the websocket session\_id (with the max always being 10). I may have misintrepted what is written. So yeah a quick spot test using the same user token. Max 10. (also concurrency checks…) ![image](https://d2opxh93rbxzdn.cloudfront.net/original/3X/a/3/a3638db058de5a5fa62b295750ca32c9198a89c3.png) > [@tduva](#): > > Seems quite limited and means that I will probably only subscribe to a single topic so I can at least get a few channels in (and keep relying on polling for what would otherwise be useful as an event like stream online/offline). End of the day it’s not really designed for you to create lots of sockets and add a load of cost 1 subscriptions to those sockets. Hence the really low limits in comparison to “webhooks” eventsub So in the use case of a discord bot reporting live/not live, this isn’t the product for you. ---
**Author:** ![rolmos](https://avatars.discourse-cdn.com/v4/letter/r/9f8e36/32.png) [@rolmos](https://discuss.dev.twitch.com/u/rolmos)\ **Post date:** [January 12, 2023, 7:26pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/14 "2023-01-12T19:26:06Z")
> The EventSub WebSocket server supports only outgoing messages. Why is it that the WebSocket connection can’t receive commands to subscribe to EventSub events vs. having to use the REST API? My guess would be it’s just simpler to use existing REST API for the beta, but I’m curious if there was also an architecture/security reason. Thanks ---
**Author:** ![Dist](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/dist/32/7192_2.png) [@Dist](https://discuss.dev.twitch.com/u/Dist)\ **Post date:** [January 12, 2023, 7:36pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/15 "2023-01-12T19:36:55Z")
I would expect one of the biggest benefits for using the REST endpoint for subscriptions is consistency, as one of the goals of EventSub is consistency whichever transport is used. While Websockets may be able to send data, that may not be the case for all future transports. If there are any architectural reasons, such as the HTTP server already being set up to handle subscription authorization and management or other reasons, then I can’t offer any additional insight. ---
**Author:** ![prod](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/prod/32/11385_2.png) [@prod](https://discuss.dev.twitch.com/u/prod)\ **Post date:** [June 12, 2023, 3:11pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/16 "2023-06-12T15:11:41Z")
Thanks for requesting feedback on the subscription limits - I’d like to reiterate my notes from the closed beta. In short, the current limits on EventSockets renders it unusable for my application. To remedy this, moderator user tokens need to allow for cost=0 subscriptions like broadcaster tokens. Currently, the `max_total_cost` of 10 is too prohibitive for my primary use case, but this would be bypassed with the mod token fix. Lastly, 300 (100 subscriptions per socket times 3 sockets) total subscriptions is not sufficient for power users of my application. My application relies on PubSub, an interface that Twitch has announced they will deprecate in the future. Twitch has promised that EventSub over WebSockets will allow for a smooth migration from PubSub, but this is patently impossible with the current subscription limits. In particular, I depend on the `chat_moderator_actions` pubsub topic for my third-party chat client, which is often used to track 50-100 channels concurrently for any given “power mod.” As a result, EventSockets must replicate access to the following data for moderator tokens to smoothly migrate `chat_moderator_actions`: - Ban/timeout: `channel.ban` exists in eventsub, but is not available for mod tokens - Unban/untimeout: `channel.unban` exists in eventsub but is not available for mod token - Clear/delete message: does not exist in eventsub (and IRC does not detail _which_ mod performed the action) - Roomstate (slow(off), followers(off), r9k(off), emoteonly(off), subscribers(off)): does not exist in eventsub (and IRC does not detail _which_ mod performed the action) - VIP added: not in eventsub, but not critical for my use case - VIP removed: not in eventsub, but not critical for my use case - Moderator added: `channel.moderator.add` eventsub, but is not available for mod tokens - Moderator removed: `channel.moderator.remove` eventsub, but is not available for mod tokens - Raid started: `channel.raid` eventsub, but is cost=1 even for moderator token - Unraid: does not exist in eventsub - Add permitted term: does not exist in eventsub - Delete permitted term: does not exist in eventsub - Add blocked term: does not exist in eventsub - Delete blocked term: does not exist in eventsub - Modified automod properties: does not exist in eventsub - Approve unban request: eventsub does not include the moderator message in `channel.unban` - Deny unban request: does not exist in eventsub In addition, my application would use the following eventsub topics that already exist (or have been promised): - `channel.shield_mode.begin` - `channel.shield_mode.end` - `channel.follow` (v2) - `channel.shoutout.create` - `channel.shoutout.receive` - Low Trust User Treatment Update - Low Trust User New Message - AutoMod Caught Message In total, my application needs over 20 eventsub subscriptions _per channel_. If we assume `max_total_cost` is not binding (with the requested mod token adjustments), this implies we’d only be able to join a measly 15 channels (300 divided by 20). This is a far cry from typical channel counts for power users of our application (e.g., I’m modded in 50+ channels). Thus, Twitch must decide whether to offer a genuine migration path from PubSub or stop pretending that EventSockets provides such a migration. With the latter option, many third-party moderation tools will suffer or shutdown. To clarify, I am _only_ asking for elevated permissions for moderator tokens within the WebSocket interface - these changes do not necessarily need to carry over to webhooks. In anticipation of comments from the usual suspects of excessively defending Twitch’s decisions, no, using webhooks and creating my own pubsub system is not viable for these use cases (and departs from the promise of a smooth transition from pubsub to eventsockets). Also, the privacy counterargument doesn’t hold water given broadcasters are already implicitly consenting to `chat_moderator_actions` use by whatever third-party applications their moderators utilize. ---
**Author:** ![ecressey](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/ecressey/32/12552_2.png) [@ecressey](https://discuss.dev.twitch.com/u/ecressey)\ **Post date:** [June 14, 2023, 4:09pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/17 "2023-06-14T16:09:43Z")
Thank you for your detailed feedback. We do intend for EventSub to be a migration path from PubSub and while we’re not there yet, we think we’ll get there soon. Your feedback definitely helps us identify the places where we need to do more with EventSub, so thank you and please continue to give us feedback! ---
**Author:** ![prod](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/prod/32/11385_2.png) [@prod](https://discuss.dev.twitch.com/u/prod)\ **Post date:** [June 14, 2023, 8:49pm UTC](https://discuss.dev.twitch.com/t/eventsub-websockets-are-now-available-in-open-beta/41639/18 "2023-06-14T20:49:51Z")
Thanks Eric for your continued commitment in supporting this migration path. Feel free to reach out if you need any clarification on my feedback - I look forward to the upcoming improvements to the product