Quicker way for determining a users 'role' in chat?


I’m using the Twitch API (alongside WebHooks) to manage my bot application. As a part of the process, I need to determine if the user is a follower, subscriber, VIP and/or moderator. I’m aware I can do this with individual calls in the API (and then cache the results), but I didn’t know if there is a quicker way to retrieve information about a user for a channel? I’ve been through the docs and can’t see anything, but wanted to ask in case there is something I’m missing.



Wait for the user to say a message in chat, then read the chat badges the user has.

Conceputally you do something in response to a chat occurance so the chat message has the data you need.

Ah I assumed that badges were only applicable if the streamer had enabled them. Is there a guide or reference to the badges that can come through on a chat message?

best bet is to look at a live chat and see what you see

See also globla badges - Reference | Twitch Developers
See also channel overrides - Reference | Twitch Developers

Generally its up to 6 slots

broadcaster | staff | channelRole | subscriber | userSelect | prediction |

Channel Role is gonna be moderator/VIP badges
User select is a vareity of things (see global) based on what the user “owns”

See also the help guides


TLDR a chat message will have any number of chat badges attached.

So read for the ones you are interested in which will be the role badges

  • broadcaster OR moderator OR vip
  • does user have subscriber badge

Right I see - is there no way to test/check this without attaching my Webhook to a stream and then chatting in it? I thought I might be able to use the Twitch CLI to simulate a chat event but looks like it’s not been updated to handle that yet.

Or connect to any stream thats live right now and watch the messages come in.

Sure this would need to be the websocket rather than the webhook edition.

But the chat message payload is the same regardless of transport

Cool I’ve managed to use a Python library to connect on and getting some badges based on their set IDs. For anyone else stumbling onto this thread, these so far are:

bits, twitch-recap-2023, subscriber, turbo, glhf-pledge, twitchcon2017, premium, no_audio, sub-gifter, moderator, partner, no_video, superultracombo-2023, rplace-2023, glitchcon2020, twitchconEU2022, bits-charity, chatter-cs-go-2022, vip, hype-train

However this doesn’t identify anyone who is/isn’t a follower. Is this only achievable via the API endpoint?

or pull the full list from Reference | Twitch Developers

as bages are added/removed periodically.


Follower information is not presented over chat.

And the API will need moderator or better access to read

There’s a UserVoice request to add follow data to IRC tags at IRC Request: Follow tag to filter out non follower messages – Twitch UserVoice - feel free to add to the vote count!

It’s unlikely to pass for the following reasons

a) moving chat to eventsub
2) follower data is protected with a moderator token so it can’t be “selective” over IRC
iii) it’s potentially expensive (in terms of cycles) and a waste of bandwidth for IRC anyway
four) it’s arguable the most useless bit of data in terms of Twitch stuff, especially if the chat is in follower only mode anyway so everyone has to be a following (ignoring mod/vip bypass)

Moving chat to eventsub? Pounding servers with HTTP requests for every message in a channel instead of using protocols that are designed for exactly this scenario? That’s gonna be awful.

EventSub offers both a webhook and a websocket transport at time of writing.

EventSub is designed to be transport agnostic.

So if you want to be pounded wtih webhooks sure.
Or you can use EventSub over websockets and not get pounded.

Further more with conduits chat bots has zero “join all rooms” downtime. You reconnect to your conduit and instantly back in all rooms

Will the WebSocket limit be increased beyond 3 simultaneous connections? That’s a particularly annoying limit for client-side code. Streamers can have non-referential duplicates or slightly differently-configured copies, running either simultaneously, or on different scenes but remaining active to allow for smooth transitions. In such cases, the total number of active clients is unknown and there’s no central controlling system, so conduits don’t really work.

Getting off topic to OP’s post now

Uservoice citing reasoning/use casing/etc.

Your bigger problem is likely handling authentication for them all most likely.

And not a problem I face with my own implimentations/setups