Update (2023-02-09): The API endpoint and EventSub subscription types have been promoted from open beta to generally available.
Last year, Twitch launched shoutouts, a new feature for streamers and their moderators to support other streamers by sharing their follow button in chat with the /shoutout command. Streamers who receive shoutouts see a notification their activity feed with the number of viewers they were shouted out to. We immediately received UserVoice suggestions for both an API endpoint to create shoutouts and EventSub subscription types to track when shoutouts happen.
Today we’re excited to launch the open beta Twitch API endpoints and EventSub subscription types for this new feature!
moderator:read:shoutouts - Read a broadcaster’s shoutouts.
moderator:manage:shoutouts - Manage a broadcaster’s shoutouts.
How do I get started?
The new endpoints and subscriptions types are publicly available in an open beta. Visit the documentation links above to start implementing shoutout functionality today. Once all UserVoice feedback is considered during the open beta, this functionality will become “generally available,” meaning no further updates or changes can be expected unless formally announced here on the forums.
If you have any questions or want to share how you’ll use these endpoints, please feel free to comment below.
The docs for ‘channel.shoutout.create’ and ‘channel.shoutout.receive’ EventSub subscriptions note ‘broadcaster_user_id’ as optional and ‘moderator_user_id’ as required in the ‘condition’, yet not setting the ‘broadcaster_user_id’ when trying to subscribe throws a validation error:
Regarding the EventSub events, I find it strange that:
channel.shoutout.create has to_broadcaster_user_id but, unlike other from/to events, there is no from_broadcaster_user_id (instead it is just named broadcaster_user_id)
channel.shoutout.receive has from_broadcaster_user_id, but unlike other from/to events, there is no to_broadcaster_user_id (instead it is just named broadcaster_user_id)
Essentially, this naming seems inconsistent with other eventsub subscription types… does this distinction exist because the condition object only has broadcaster_user_id (without an explicit from/to prefix)?
Would it not be better to follow the example of channel.raid where there is only one subscription type & you either specify from_broadcaster_user_id or to_broadcaster_user_id?
Edit: the activity feed mess may be related to this distinction but I don’t understand why you need to tie yourself to that system if you have all the .create events
I’ve been trying to implement this today as part of an existing script we have for on-stream alerts and discovered shout outs can’t be processed (400 - bad response) when the streamer is not currently streaming and I am completely baffled as to why that is.
The vast majority of shout outs we do are when streamers stop by in their offline time, so this end point can’t be used to do it’s job. If someone has just raided then by the very nature of raiding, they’re no longer streaming, so again, it can’t be used in that context either, so really what is the point? I guess I’m going to have to go back to trying to figure out how to write my own chatbot app from scratch in order to work around this incredibly stupid and frustrating ‘feature’.
Ok, I’m a dumb**s - thank you for pointing out my mistake! I retract my entire complaint! I’m honestly very grateful, if also slightly embarrassed! Although I will say I’m not the only person I know who mis-read it as such!