EventSub WebSockets are now available in open beta

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.

11 Likes

2 Likes

Nice!

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.

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

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.

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.

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.

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.

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.

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

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).

I may have misintrepted what is written.

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

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.

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

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.