Deprecation of chat commands through IRC

Is there going to be a way to request higher API ratelimits, now that we’re being forced to migrate calls to Helix? Going from verified bot IRC ratelimits to something significantly smaller certainly is going to hurt.

Open up the get moderators and get VIPs endpoints to not require a broadcaster token. It’s a little ridiculous to need a broadcaster token to get that info, when any registered user can simply type /mods or /vips in Twitch chat.

I get why most of these changes are coming, I had a feeling as soon as the moderation endpoints were rolling out. But we need to be able to request higher rate limits now since you’re pushing us all to use Helix. Forcing Helix usage without rate limit adjustments is a step back in functionality. Sure, I can get around it by using the broadcaster’s token to perform certain actions, but I shouldn’t have to.


The API currently only supports doing timeouts as the access token’s user. So when you’re using the broadcaster’s token to timeout, the users in chat and the chat logs see the timeout as coming from the brodcaster (and not the app’s account) Using an app token is not viable here because the singular app token rate limit doesn’t scale with timeouts unfortunately.

Is this an issue that can be resolved somehow?
E.g. if it’s a broadcaster’s token, the “moderator_id” can be set to the user-id of the account the client-id belongs to (without the access token necessarily coming from that account)

use a token that represents the modertor not the broadcaster.

Any endpoint that uses a scope starting moderator: supports using a token that is from a moderator of the channel.

So you should get the bots or a moderators token, not the casters token, when you want to timeout someone.

That’s the problem. You’ll then be limited by that singular rate limit (the bot’s token) across all the channels that you moderate.

The point of using user tokens is that each “channel” has its own token, and thus its own rate limit. So channel A doesn’t use the rate limit of channel B.

1 Like

It was unclear to me that was the problem. (And missed in my initial thoughts)

But I feel the helix rate limit might be sufficent, since the mystery ban limit is per channel.

So I think the intent is you can wack as quickly via the API as you can via chat. But this might need the older IRC command proxies to die to clear out engineering resources first.

Any Twitch account that already had verified bot status will continue to have the higher Whisper limit of 20 per second, up to 1200 per minute, for 100,000 accounts per day.


So that will be going away…
I find it interesting that it’s not too difficult to have rate limits based on account type and even when the account got that status, but it’s too difficult to not make developers jump through hoops just so things continue working, albeit with higher bandwidth requirements and additional latency.

It makes me think of a Steve Ballmer quote preceded with one of his favorite words.

1 Like

I already tried moving away from IRC commands a year ago but I was unable to because the endpoints I needed required a broadcaster token :slight_smile:

I even found a uservoice post that exactly described my issue but it has been open for 2 years with no response :slight_smile:

1 Like

(Generally) Any endpoint that uses a scope starting moderator: will work with the bots own token. (as long as the bot/user authed as is a moderator in the channel you wish to take actions on.

This covers all commands except commercial, Get Mods and Get VIPS. Which yes as you note requires a broadcasters token.

And a bot can still obtain moderator (or VIP) status by interrogating the tags on a recieved PRIVMSG

So, one command was missing from the API, and instead of just adding it and supporting both you rip out all the other IRC commands that were working fine. That makes a whole lot of sense. Kappa

Why not support both?


To make bot/scripts/socket users operate in a similar way to the main website does.

And then be able to make additional improvements to chat in the future.

Come February, will we get rolling sunset windows where the IRC commands are disabled so that folks who don’t see this announcement will notice something is wrong (and have some time to migrate before an abrupt shutoff)?


After removing chat-specific commands from chat, what’s next?

JOIN/PARTs are already not reliable. We’re still waiting for the promised improvements. Maybe ripping all of the chat commands out of chat will fix it?

There is an endpoint to send chat messages, so why not force all the messages to be sent through that? And keep its 12 messages per minute limit, if we’re ignoring previous limits anyway.

It’s been requested for a while to have a public endpoint to get recent chat messages. If you add that, then you can remove tmi entirely. That will resolve the “unfortunate segmentation of functionality” and is consistent with the “effort to group all actions under the Twitch API”. That could be an “improvement to Twitch Chat”.

“[S]ome actions that you would typically leverage via an API” and definitely not from within chat itself include: announcements to chat, bans from chat, clearing chat, deleting messages from chat, options for controlling who can chat and how, as well as determining which users have special privileges in chat, and other ways to chat.

It’s clearly best to have commands related to chat not be available from within chat. Of course they “will still be available within Twitch-owned chat interfaces such as a channel page on or in the mobile apps”, “but third-party developers must” do extra work.


You do realise that chat commands on the website don’t go out via the chat socket anyway.

So this change brings chat commands for developers in line with how chat commands operate on the website.

For end users there is no visible difference, since end users already have “API Chat commands”

Case in point: the new announcment command.

IRC/Socket users only got the default announcment color. /announcepurple wasn’t made available to socket users. This is API only. And when all chat commands are API only it’s a level playing field for Website/Socket. And easier for Twitch to Develop if they don’t have to consider API support and socket support. (which was ignored for /announce)

1 Like

A follow-up question regarding the limits of “bot” user tokens for “moderation” tasks.
Will the request be in the same total “bucket” limit as the regular API or will they be unique per “broadcaster_id”. Thinking specifically for all API endpoints based on the scopes: “moderator:manage:*” and “moderator:read:*”.

If they are actually under separate buckets of the rate limits, it would be nice to get some clarifications regarding this, or at least some information what is planned to happen. Because if the user token will be limited by the global limit for those actions, there are going to be a lot of troubles in handling larger amounts of channels, when a lot of automated moderation is wanted.

I feel as of now the documentation here: Twitch API Concepts | Twitch Developers does not describe this perfectly well, specifically the part:

Your app is given a bucket for app access requests and a bucket for user access requests. For requests that specify a user access token, the limits are applied per client ID per user per minute.

If an endpoint uses a non-default points value, or specifies different limit values, the endpoint’s documentation identifies the differences.

PS: Yes, I have seen that Barry made a comment regarding some “Magical” limit per channel previously as a vague answer:

But I feel the helix rate limit might be sufficient, since the mystery ban limit is per channel.

EDIT: Did some testing after posting this, and tried to ban several people in the same or different channels with a user token. The headers responded back do not seem to reflect the correct values as expected, it continuously says “remaining: 799” at all times.

Assuming things work…

As it’s written, the bucket used will be the user bucket of the moderator user whose token is used to do the action. In other words, in a typical case where your bot uses a single user account, all moderation actions count against the same limit, regardless of channel/broadcaster_id. If you use the broadcaster’s token instead, then the limit will be effectively per-channel, but someone mentioned it will appear to be done by the broadcaster him/herself, which may be undesirable.

This just means it refilled a point in the time it takes to make a request

Even though I sent 5 requests directly after each other, where all 5 requests succeded to perform the “ban” request?

Generally it can be hard to make the helix limiter depress the remaining or so I have found

1 Like

Sure that is a solution, but as described above… this adds another issue. If the user changes password etc, the token will be killed and they have to “re-sync”.

Instead of having a single bot account, the developer instead needs to maintain it. But also add new scopes as the twitch API continues being developed over time. So for me, this is a no go solution with using the “broadcaster” token.

BanUser calls actually consume from two buckets:

  • The global helix rate limit for the client_id-user_id pair: 800 points, 600/60s refill
  • Channel-specific bans bucket: 100/30s per channel (unofficial & likely per mod_id)

For “Ban User”, the remaining header is not particularly meaningful, as it reflects the former (global limit) rather than the latter (ban-specific bucket)


I do agree that all these IRC->Helix changes should be accompanied by more clear & explicit documentation for these endpoint-specific rate limits