Twitch Suspicious User Signals: Should Restricted or Monitored Chatters Reach Paid TTS?

The question moderators are already asking

A moderator opens the paid queue and sees a message from an account they do not recognize. In Twitch chat, moderators can see that the same account is flagged as monitored. The queue gives no hint of that. The moderator has two systems telling two different stories and has to guess whether the Twitch warning should change what happens to the paid message.

That gap is now closeable. Twitch exposes suspicious-user information to tools that a moderator has authorized, which means a paid queue can know what the chat already knows. The harder question is what to do with it. Block everyone flagged and you will punish people for a guess. Ignore it and you leave a safety signal on the table. The useful middle is a defined review rule.

What Twitch actually sends

Twitch's EventSub reference lists two subscription types for this. channel.suspicious_user.message fires when a chat message is sent by a suspicious user. channel.suspicious_user.update fires when a moderator changes how the channel treats that user. Both subscriptions need a moderator_user_id in the condition, and the docs say that moderator must have permission to moderate the channel and must have granted your app permission.

The message event carries a low_trust_status that can be none, active_monitoring, or restricted. It also includes shared_ban_channel_ids, a list of channel IDs where the user is also banned, and a types list that can contain manually_added, ban_evader, or banned_in_shared_channel. A ban_evasion_evaluation field holds Twitch's automatic likelihood estimate, which can be unknown, possible, or likely. The message itself arrives as structured fragments, and fragments can include cheermotes.

Twitch also documents held-message events for AutoMod and user message holds. Those are about messages Twitch caught for review. Suspicious-user signals are about the person. Your queue should be able to tell the two apart.

Chat signals do not automatically describe a paid submission

Here is the part people skip. The suspicious-user events describe chat messages and chat accounts. A paid TTS message is usually typed on a tip page or a paid-interaction page, not in Twitch chat. A flag on a chatter helps your queue only when your tools can connect a paid submission to that Twitch account.

That connection exists in some flows, such as a viewer who signs in with Twitch before submitting or a chat-command-triggered request, and does not exist in others, such as an anonymous tip with a typed name. Check how your own setup identifies the person behind a submission before designing a rule around the signal. If the link is a typed username, treat it as a weak match and do not let it drive a hard decision.

In a moderated paid queue such as the one StreamableBot is built around, the realistic use is display and routing: show the moderator the status next to the item and route flagged items to review. The rest of this post assumes that connection is reliable in your setup.

A rule per status

Keep the rule short enough that a moderator can recall it without a document. Three statuses, three behaviors.

None means the normal path, including any auto-approval you already allow for low-risk items. Nothing changes.

• none: normal flow. Auto-play only if your existing rules already allow it for that item type.
• active_monitoring: the item still goes through, but it always waits for a moderator decision. No auto-play, even for short text.
• restricted: the item is held and needs a named moderator's approval. Prefer text-only handling or a skip for audio and image items unless the streamer has said otherwise.
• Any ban_evasion_evaluation of likely on top of either flag: escalate to the streamer or lead moderator before approving.

A flag is a prompt, not a verdict

Twitch labels the evasion estimate as unknown, possible, or likely. Those are estimates. A person can be flagged by mistake, a moderator can add someone manually after a bad night, and a shared ban in another channel might reflect a different community's rules. Using any of that as proof turns a signal into a punishment.

That is why the rule above asks for review rather than refusal. A moderator who reads the message and sees a harmless joke can approve it. A moderator who sees something off can reject it with a plain reason. The signal makes the second look happen. It does not replace it.

Keep the flag away from viewers

A moderator-only status is a moderator-only status. Do not print it on the overlay, do not read it out in a reject message, and do not put it in a chat reply. Telling a viewer that they were flagged as a likely ban evader in a public setting is a good way to start an argument and a bad way to run a calm stream.

Reject reasons should be ordinary. Not approved for this stream, or held for review and not selected. If the viewer asks why, the answer comes from a moderator in a private channel, not from the bot. The queue should show the status in the moderator view and nowhere else.

Moderator notes need the same discipline. Writing a status next to a name is useful for the shift. Copying it into a shared document that other volunteers can see, or pasting it into a Discord thread, spreads a guess far beyond the people who need it.

One source of truth: Twitch's own list

Twitch has its own Suspicious User Controls where a streamer or moderator sets how the channel treats a chatter, and Twitch's help center explains what each treatment does in chat. Read that article for the current behavior instead of relying on summaries, including this one, because the platform defines what restricted and monitored mean for the chatter.

Your queue should read status from Twitch, not keep a parallel list. If your tool lets moderators mark someone as risky inside the queue, you will eventually have two lists that disagree. When the update event fires because a moderator changed a user's treatment, your queue should change with it. Keep the platform as the place where the decision is made and use your queue to act on it.

Who authorizes what

Because the subscription condition names a moderator, the authorization belongs to a person, not just to the channel. That has operational consequences. If the authorizing moderator leaves the team or revokes the app, the signal may stop arriving, and the queue will quietly return to treating everyone as none.

Decide ahead of time who the authorizing moderator is, put it in the handoff notes, and test the signal after any change to the mod team. A good indicator is a visible line in the moderator view that says whether trust signals are connected. Silence should not look the same as everything being fine.

What happens when an item is already paid

Review comes after payment in most setups, which means a rejected item has a cost. Decide the outcome in advance. Common options are a credit for another submission, a replay at a later segment, or a refund under your own policy. Whatever you choose, apply it the same way regardless of status so flagged viewers are not treated worse because of the flag.

Keep a short audit entry with the status at decision time, the moderator, and the outcome. If a viewer complains later, the record shows the decision was a review, not an automatic block, and that the same refund rule applied.

A short test before the next stream

Use a throwaway channel or a quiet moment. Ask a moderator to set a friend's account to active monitoring, then send a message from it through whichever route links submissions to Twitch accounts. Confirm the item arrives with the status visible, no auto-play, and no public mention. Flip the status to restricted and check that the update event changes the queue behavior. Flip it back to none and confirm the normal path returns.

• Moderator-only status shows next to the item and nowhere public.
• Monitoring forces review. Restricted forces named approval.
• Update events change behavior without a restart.
• Removing the authorizing moderator produces a visible warning, not silence.