Twitch Guest Star Sessions: When Paid TTS and Alerts Should Hold for a Live Guest

A paid voice in the middle of someone else's sentence

Most paid TTS features are designed around one person: the streamer. A viewer pays, the voice plays, the streamer reacts, and the show moves on. Add a guest and the picture changes. The synthetic voice now cuts into a conversation between two people, one of whom did not agree to your monetization rules, and a viewer may have just paid to say something about them.

Twitch's Guest Star feature makes this common because it puts guests on stream with a built-in invite and slot workflow. It also gives tools something useful: a documented set of session and guest states. This post is about turning those states into a clear paid-moment policy.

What Twitch exposes, and its beta label

Twitch's developer docs list Guest Star endpoints for reading and updating channel settings, getting, creating, and ending a session, sending invites, and assigning and updating slots. Every one of them is marked beta in the API reference. The EventSub list has matching beta events: channel.guest_star_session.begin, channel.guest_star_session.end, channel.guest_star_guest.update, and channel.guest_star_settings.update.

The session events carry a session ID, with started_at on begin and an end timestamp on end. The guest update event is the interesting one for paid moments. It reports the guest and host, the session ID, a slot ID, the moderator who made the change (null if the guest did it themselves), and a state.

Because the label is beta, the shape can change. Keep any integration thin, log what you receive, and always have a manual way to do the same thing.

The states that matter

Twitch documents six guest states. Invited means the guest is in the invite queue, including when a guest was removed from a slot and sent back. Accepted means they accepted and are setting up. Ready means they have signaled they are ready and can be assigned a slot. Backstage means they have a slot but are not seen live in the broadcasting software. Live means they are live in the host's broadcasting software. Removed means they were taken out of the call or queue.

For a paid queue, only a few of those change anything. Backstage is a warning that a guest is about to appear. Live is the moment the policy applies. Removed or a slot going empty is the signal to release. The earlier states matter to the person running the invites and not much to the person running the queue.

• backstage: warn the queue team that a guest is about to go live.
• live: switch to the guest-segment mode.
• removed or empty slot: return to normal and drain the backlog gently.
• invited, accepted, ready: no change for paid moments.

Pick a guest-segment mode in advance

Three modes cover most shows, and the right one depends on what the segment is. An interview wants quiet. A co-op game can take more noise. A chaotic party stream may want almost everything open.

Choose before the guest arrives and write it in the moderator notes. Changing it live in the middle of a conversation is exactly the kind of decision nobody makes well.

• Full hold: no TTS audio and no sound alerts. Visual cards may run quietly. Best for interviews and serious conversations.
• Soft: TTS only in natural pauses, approved by a moderator who watches the conversation. Best for a mixed show.
• Open: normal operation with shorter reads. Best for fast co-op play where noise is expected.

Keep the guest's ears clear

Twitch's guest update event includes host_audio_enabled and host_volume, a value between 0 and 100 describing the slot's audio level as heard by participants within the session. That is a reminder that there are two audio worlds: the broadcast mix viewers hear and the call mix participants hear.

Where your paid TTS goes depends on your audio routing. If you capture your desktop audio or a virtual device and feed it back into the guest's return, the guest hears every paid message in their own ear while they are trying to speak, and your microphone may pick up the echo. Test it with a friend before the real guest. Ask them what they hear when a TTS message plays.

The fix is routing, not policy. Keep the TTS and alert sources on the broadcast mix only, and send the guest a clean return that contains the conversation and nothing else. If you cannot confirm that, use Full hold during the guest's time on screen.

Messages about the guest

Paid text is more sensitive when a guest is present. A joke that works about the streamer, who accepted the format, may feel different when it is about a visitor. A viewer might also pay to ask the guest something personal, to repeat something, or to say something at the guest's expense.

Tighten review for the duration. Messages that name or target the guest go to a moderator before anything else, and the default answer for borderline items is to defer until the guest has left. If a guest wants a veto, give them a simple way to signal it, such as a word or a gesture the moderator watches for, and agree on it before the show.

Brief the guest on what viewers can pay for. A short conversation covering which paid features are on, what is held during the segment, and how the queue is reviewed is enough. Treat it as the same courtesy you would give someone about clips and recording.

Two moderator jobs, not one

The guest update event includes the moderator who changed the guest's state, and Twitch's settings event includes a flag for whether moderators can send guests live. That tells you the platform already treats slot control as its own job. Someone is inviting, assigning slots, and sending guests live.

That person is not watching the paid queue. If one moderator is expected to do both during a busy segment, one of the two will fall behind, usually the one with the quieter alert. Put the roles on different people when you can, and agree on the cue between them: the slot moderator says live in the mod channel, the queue moderator switches the mode. The event log gives you a record of who moved a guest, which is useful when you review the show afterward.

Without a second moderator, the streamer or a tool needs to carry one job. In that case prefer Full hold for the segment, because it removes a decision.

Handle empty slots and missing fields

If you consume these events automatically, read the field descriptions carefully. Twitch says the guest fields are null when the slot is now empty, and the slot ID is null when the guest is in the invited, removed, ready, or accepted state. The host audio and video fields are null if the guest is not slotted.

A parser that assumes every field is present will fail on exactly the events that matter, such as a guest leaving. Treat nulls as normal, and treat an update with no guest as a release signal rather than an error.

Release the backlog slowly

A full hold builds a queue. When the guest leaves, playing everything back at full speed turns the first minute afterward into a wall of TTS and a flood of apologies from the streamer. Drain it at a controlled pace, with the oldest items first and the streamer's reactions leading the rhythm.

If the backlog is long, say so on screen and spread it across the next few minutes. Viewers who paid during the guest segment will accept a short wait if they see a plain line like: paid messages saved during the interview, playing now in order.

A rehearsal worth doing once

Run a session with a friend before a real guest. Invite, accept, ready, assign a slot, send them live, remove them. At each state, check what your queue does or what the moderator is supposed to do.

• Backstage triggers a warning to the queue team.
• Live switches the segment mode, and the viewer-facing status changes.
• The guest hears conversation only, with no TTS in their return audio.
• Removal and empty slots release the backlog at a controlled pace.
• Null fields do not crash the tool, and a manual hold still works if events stop.