Important re-subscription change

Hey, developers!

On Monday, June 20th, we’re making a breaking change to our chat protocol around re-subscription notifications. We’re going to change how IRC receives re-subscription notifications and allow subscribers to send custom notes with their re-subscription. Here are the technical details:

When sharing a re-subscription, twitchnotify no longer sends a PRIVMSG to IRC. Instead, you’ll receive a USERNOTICE with all of the existing tags along with a few new tags.

NOTE: All other PRIVMSG commands from twitchnotify are unchanged. This only applies to resubscription messages. New subscriptions will not send a USERNOTICE.

New tags

  • msg-id
  • system-msg
  • msg-param-months
  • login


With user message, to streaming channel

@badges=staff/1,broadcaster/1,turbo/1;color=#008000;display-name=TWITCH_UserName;emotes=;mod=0;msg-id=resub;msg-param-months=6;room-id=1337;subscriber=1;system-msg=TWITCH_UserName\shas\ssubscribed\sfor\s6\smonths!;login=twitch_username;turbo=1;user-id=1337;user-type=staff USERNOTICE #channel :Great stream – keep it up!

Without user message, to streaming channel

@badges=staff/1,broadcaster/1,turbo/1;color=#008000;display-name=TWITCH_UserName;emotes=;mod=0;msg-id=resub;msg-param-months=6;room-id=1337;subscriber=1;system-msg=TWITCH_UserName\shas\ssubscribed\sfor\s6\smonths!;login=twitch_username;turbo=1;user-id=1337;user-type=staff USERNOTICE #channel


Will we receive a USERNOTICE for new subscribers?

No. The USERNOTICE only applies to re-subscriptions.

Is the login tag the username or display name?

The login tag is the lowercase username. The display name is sent in the display-name tag.

What is the value of the room-id?

The room-id is always the channel where the user re-subscribed.

What happened to the third scenario that used to be here?

We removed it. We do nothing special in the hosting scenario.

Let me know if you have any questions! Sorry for the short notice on this.


It’s fantastic that the month and username is being passed as parameter. No more extracting that stuff from the message. It be great though if the target channel could be passed too for hosted channel so we don’t have to scan for that. Also quick question, is the name the display name or the lowercase username?


Would it be too much to ask to have a tag for the channel that was re-subscribed to, to filter ones sent as part of hosting? Otherwise we’re still going to need to parse the system-msg and the tag for months will be essentially useless.


The only difference between
Without user message, to streaming channel
Without user message, to hosting channel
is in system-msg tag?
if room-id also will be different you should send it in for example ROOMSTATE (or JOIN) as tag (doing https api request to get room id looks bad) to bots can put it in map or add room name tag to check is channel is same by room id or by room name

I second this. A tag for “target” room that the person is resubbing too would be most helpful.

That said getting a USERNOTICE for someone not technically in the room is weird :stuck_out_tongue:

Third for target.

Also clarification on ;login=TWITCH_UserName;

This is the LOWERCASE twitch channel name, or MiXeDcAsE display name?


These are the critical items (in my eyes)

  • sub-room-id (User subscribed to this channel. (dealers choice on how they want to handle this tag, knowing the hosting channel that sees the sub would be useful for my purpose (Example line: room-id=12345;sub-to-room=9876;user-id=5555 would mean that room 12345 is hosting 9876, and user 5555 subscribed to 9876)
  • Twitch channel id for subscribed user
  • Preferably the lowercase channel name
  • Number of months subscribed

Most of those items are covered with this message, so I’m happy - out of curiosity: When a resub message is coming, why would the subscriber=0? Wouldn’t subscriber by definition = 1? Going to chaulk it up to example line.

Please also identify which (if any) cap requests are required to receive the changed message so there’s no ambiguity.

According to existing documentation and behavior, it would be commands to get the custom command in the first place and tags to have tags included with it.

Just FYI, I’m gathering information for your questions. I’ll keep you posted! :slight_smile:

A few points of clarification for @3ventic, @tournymasterbotCurse, @BarryCarlyon:

  • login tag is always lowercase. This was my fault. I’ll update the OP. :slight_smile:
  • subscriber would be = 1. Poor example skillz. :stuck_out_tongue:
  • CAP requests are the same as PRIVMSG.

An overall question for you all and @EhsanKia: Currently, this is how the USERNOTICE works for hosting: A host (room-id: 1) hosting a channel (room-id: 9000) that receives a resub will receive a USERNOTICE command with room-id=1 (host’s ID). The hosted channel will receive a command with room-id=9000. There are no plans to add additional tags. Help me understand the use case for having both room IDs in the tags, which is what I think you’re asking for. What do you do with it? Currently, do you have to parse the message, take the name in the middle, and call the API? Trying to advocate for the change internally but need more info. :slight_smile:

Basically, most applications do not care about resub messages of other channels, so we filter it out. Right now, with the current data we have, there’s no way to tell them apart, other than having to parse the message itself.

Message parsing is dirty, because any time you guys decide to change the message, it could our parsing. It’s like scraping websites, a proper API is far better than extracting things yourself out of the page. This is why we need some way to know who the resub is for.

Also, it’d be great if we could have the display name in there too.

1 Like

Stupid question but for clarity:

room-id will be the ID of the Room the Resub is for:


Where x is the RoomID of the channel the user is resubscribing too?

Additional questions:

  • Is a room ID the same as the _id from or how/where would one obtain RoomIDs (in b4 roomstate on room join)?

  • In vanilla Twitch, where/how will the the user entered messages be shown to the broadcaster?

First time I hear about “USERNOTICE”. Did you mean “USERSTATE” or is it new?

Oh so the room-id will be the room that was subscribed to. That’s good enough. The examples all had the same room-id so I thought it was the channel the USERNOTICE was sent to, like with other messages. Thanks for the clarification.

USERNOTICE is new. It isn’t USERSTATE, @novayuna

@BarryCarlyon, the message appears in chat. The broadcaster would have to be watching chat to see it. I’m confirming your other question with the engineering team.

@3ventic, I’m confirming this to be the case. The text above was directly from the engineer, but I want to be 100% clear.

Hey, devs!

We’ve move the release to Monday, June 20th. We had some internal discussion about this and decided to move it away from the middle of E3 so that more folks are available. I learned about this today, so I wanted to give you the heads up ASAP.



Thanks for the heads up. The improved communication about API updates is definitely appreciated!

edit: scrolled down and dallas answered most of these already WOOT

@3ventic we’re re-evaluating the usefulness of these messages in the 3rd case entirely, so it may be moot.

@tournymasterbotCurse login refers to the undercase username. ie ‘xangold’ I don’t see ;login=TWITCH_UserName; (cased version) anywhere in Dallas’s message, other than in the system-msg tag?

1 Like

Yeah, he edited it from my question :stuck_out_tongue:

Will a first subscription also be considered a “resub” (msg-id) with msg-param-months set to 1?