Hi Twitch team,
I’m moving an overlay from local testing to production. Broadcasters will add a public URL like:
https://<subdomain>/broadcaster/<random_hash>
The overlay runs in OBS (outside the Extension iframe). When a Bits EventSub callback fires, my backend pushes an animation event over a WebSocket to any connected overlays for that broadcaster.
Because the page is outside Twitch, there’s no Twitch JWT available in the overlay. My plan is:
-
Treat the URL as a capability link:
<overlay_id>+ a secret kept in the URL fragment. -
The overlay page reads the secret from the URL fragment (not sent to the server in the initial GET), exchanges
{overlayId, secret}for a short-lived server-issued JWT, then connects:
wss://<subdomain>/ws?token=<jwt> -
WS upgrade verifies
aud/iss/expand attachesoverlayId/broadcasterId. -
EventSub (Bits) → look up sockets by
broadcaster_id→ push animation payload.
Questions:
-
Is this an acceptable approach under Twitch policies for overlays outside the Extension iframe?
-
Is there any Twitch-provided token recommended for this OBS use case, or should I fully own auth as above?
-
Any recommended validation pattern for the public overlay URL beyond strong random IDs + my own auth?
-
Any guidance/limits for many WS connections from OBS browser sources (reconnect, rate limits, CDN/proxy considerations)?