How to subscribe to events with Twitch CLI EventSub websocket server

My Javascript web app (Browser) runs fine when I connect to the actual EventSub (beta) URL:
wss://eventsub-beta.wss.twitch.tv/ws

Subscribing to events

I connect the websocket and issue separate calls to https://api.twitch.tv/helix/eventsub/subscriptions with the type and session_id. (which works with the live API)

But I can’t figure out how to test that it correctly responds to eg. channel.cheer or channel.subscribe. I tried to set up the Twitch CLI and its EventSub websocket server. I can connect fine, but the logic that subscribes to the events fails API calls with HTTP 400 Bad Request – websocket transport session does not exist or has already disconnected

Which kind of makes sense? Since the official API does not need to know about my Twitch CLI setup over here. But how do I do it instead?

I tried working with the CLI mock data server, but the docs explicitely state

The mock server replicates a majority of the Twitch API 
endpoints except for endpoints related to:

- EventSub

So my hopes of subscribing to events this way are low.

Triggering events

I also tried triggering events according to Test webhook events | Twitch Developers, but that would not do anything either:

twitch event trigger subscribe -F http://localhost:8080/eventsub/

returns

✗ Invalid response. Received Status Code: 404
✗ Server Said: 404 page not found

even though the server is running (I’m connected via websocket!) Seems it’s just not a http server.

I’m guessing I have not wrapped my head around how the workflow is supposed to be working. I’m thankful for any suggestions.

1 Like

Currently the Twitch CLI’s mock server only lets you test connect/reconnect logic

You cannot currnetly use the CLI to test events sent to a EventSub WebSockets.

So the problem here is that the CLI is not ready for full mock testing of eventsub websockets.

1 Like

Thanks for the reply. I guess this is why EventSub via websockets is labeled beta.

I’ll try and come up with a way to manually inject the messages into my app, but some are hard to understand from the docs, eg. whether there is a way to determine who gifted a sub. So when somebody gifts 100 subs, the app doesn’t spam 100 sub notifications after. Or collects them into a single notification.

I guess the CLI can at least produce valid JSON responses I can try to work with.

I think in my case it may be better to work with PubSub instead, but I’d be missing out on some features eg. follow notifications.

there are a couple of uservoice open on this one to improve EventSub for Overlay builders for things like this

The idea is the EventSub sends the same data layout regardless of the transport used.

So you can run tests via “webhook” eventsub if needed and then swap the logic to a websocket.

Or have a server, webhook into the server and the server forwards to a socket. and instead of connecting directly to Twitch you connect to your server as a proxy.

All very good ideas! Ideally I’d like to do this without having to set up a proxy server, since I’m building a self-contained entirely front-end overlay display for OBS etc., so I’d like it to be easy to set up for less tech savvy users. But I’ll look into how I can build the logic to simulate events myself, based on the JSON output in the docs.

Thanks again!

A proxy server may be a better option here.

As to be selfcontained inside OBS, you’ll use implicit auth and that token is non refreshable and valid for only 60 days, sure yo ucan store it in storage between restarts.

But when the token dies the streamer will likely need to interact with the browser source to grant a new token. Which might be sometimes seemless but difficult if it breaks for a user to understand a fault has occured and might need to manually perform a task. (Since you are also in a self contained context without access to normal password managers/etc)

Websocket subs only exist for the lifetime of the socket.
Webhook subs stick forever (until clientID revoke)

My personal choice would be the proxy server here.
Or run a desktop app that handles authentication and serving of the overlay, as if the token dies I can present a suitable error and reauth inside the app. And said app can also act as an event reader/list which is easier to scroll to see history/etc.