EventSub WebSockets are now available in open beta

Announcements
1

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 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 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 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. You can use the Twitch Developer Forums or the TwitchDev Discord server 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.

10 Likes
2

1 Like
3

Nice!

4

Question on the 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.

5

A single websocket can have 10 cost 1 subscriptions on it.
So you will run into that limit first

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…

1 Like
6

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.

7

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.

8

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.

9

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.

10

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.

11

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 and others… )

12

Is that really how it works? The documentation 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).

13

I may have misintrepted what is written.

So yeah a quick spot test using the same user token. Max 10. (also concurrency checks…)

image
image2036×779 119 KB

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.

14

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

15

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.

16

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.

7 Likes
17

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!

2 Likes
18

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

1 Like