Trouble with EventSub Websocket Auth

I am currently trying to setup an app to listen for chat events over a websocket, and eventually send responses to certain chat messages. So far I’ve been following along with the documentation here:

However I’m having trouble with understanding which tokens I need. Specifically I’m having trouble with this portion of the docs:

It mentions that I need 3 tokens total:

I’m having so much trouble with the 3rd one. I cannot for the life of me find instructions for creating a USER access token for a BOT. All of the user access token methods redirect me to sign in through my browser with my actual Twitch account’s credentials (which is the streamer account in my case). If I go ahead and do this for both of the user tokens and the scopes that the docs define, then I receive a 403 when attempting to subscribe to the channel.chat.message Event with my bot user as the condition.user_id.
If I set my own channel ID as the user_id then the request succeeds, but this is not what I want as I want the bot to be the one reading the chat messages (at least this is how it’s shown throughout the rest of the docs).

My question then is, how can I generate a user access token for my bot with the needed scopes? And could the documentation be updated to make this clearer if I’m not just missing something obvious?

Thank you in advance

For reference, here is the request I’m sending to subscribe to the event

def registerChat(session_id):
    res = requests.post(
        "https://api.twitch.tv/helix/eventsub/subscriptions",
        headers={
            'Authorization': f"Bearer <Streamer User Token with user:read:chat user:write:chat user:bot permissions>",
            'Client-Id': <My Client ID>,
            'Content-Type': 'application/json'
        },
        data=json.dumps({
            'type': 'channel.chat.message',
            'version': '1',
            'condition': {
                'broadcaster_user_id': <Streamer ID>,
                'user_id': <Bot ID>
            },
            'transport': {
                'method': 'websocket',
                'session_id': <Websocket session ID>
            }
        })
    )
    print(res.text)
    res.raise_for_status()

Straight websockets take only a user token from the user you want to read the chat as

Example: EventSub WebSockets Chat edition with Implicit Auth Example

My Documentation: twitch_misc/eventsub/websockets/web/chat at main · BarryCarlyon/twitch_misc · GitHub

Just generated user access token with the following scopes

  • user:read:chat from the user you wish to read chat as

You then use that user access token to create subscriptions to your socket.

You only need three tokens if you are doing Webhooks or conduits transports.

When doing straight websockets you need only a token from the bot account/user to read chat as with the scope user:read:chat (minimum), you don’t need a client credentials token or a token from the broaadcaster

“bot accounts” are just “regular twitch accounts”

So you get auth the same was as you would any other user, direct the user to login with twitch and grant permissions.

To “switch logged in twitch accounts” either

  • use force verify on the link so a user can check/switch accounts first (a), as otherwise due to no scope change it just goes
  • direct the user logged in as someone else that has a second bot acccount to use incognito mode (b)
  • if you own both accounts and doing it yourself, you can go to twitch.tv and logout of the site completely before starting the oAuth flow
  • just use another browser where you are not already logged into main

logically it’s easiest to use incognito or another browser

(a) see the “not you? log out” button

(b)

So when I need to get new tokens for the bots I run and control/own the bot accounts I’ll use another browser or incognito to complete the flows

It’s “basic” oAuth to get permissions for account (x) you first need to be logged into service (y) as (x) or on the oAuth dialog use the account switcher if one is available or can be prompted for

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.