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.
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.
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.
In case anyone finds this: I did make it into a crude website that can be embedded in OBS as a browser layer. It’s not very well tested and I make no guarantees, but it kind of works.
Use at your own risk. And know this was made when the eventsub websocket API was still in beta.