Channel Points is a customizable system for delivering points to members of a streamer’s community which are then redeemed for rewards or perks on that streamer’s channel. Channel Points provides automated built-in rewards as well as a way to create custom rewards that are fulfilled by the streamer (e.g. “choose who we raid next”). Today, we’re exposing a PubSub topic that receives messages for custom reward redemptions.
What’s new?
A new OAuth scope is being added to read custom redemptions: channel:read:redemptions. When using the new PubSub topic, please make sure to use this scope.
The new PubSub topic to listen on and receive redemption messages is channel-points-channel-v1.userid. Please see the documented example for the response and a table that provides context for the data provided.
Why are we adding this product?
We want to begin providing Channel Points functionality to developers so they have the opportunity to create exciting and unique experiences for broadcasters using this feature.
Known issues
All redemptions will have the state of unfulfilled as fulfillment messages aren’t being sent on this topic yet.
What’s the future of the product?
In the future, we are considering building webhooks for these rewards and other updates developers might want to know about, as well as a set of API endpoints. The functionality of these endpoints could include reading a users rewards state, creating rewards, and using points.
Is there a timeline on when will we be able to mark redemptions as fulfilled/rejected via the API? This is something we can already do via wrapping the reward queue page, so having a reliable callback to handle redemptions is pretty key to using these reliably.
Thanks for the questions related to future development. While we are investigating which API endpoints will be helpful to take full advantage of Channel Points programmatically, we cannot provide a date just yet. However, it is top of mind so you can most likely expect an additional announcement sometime in the new year after development and testing is complete.
Is it intended that you can only listen to the topic for your own channel? I would have hoped to also see redemptions in other channels, since currently it’s only possible to see custom rewards that have a message attached through IRC. They also only have a custom-reward-id=<id> attached, with no way (that I know of) to translate that into the reward name.
So it would be great if it would be possible to either listen to other channels as well (although that may not fit your intended access model) or at least a way to translate custom reward ids into a reward name.
The PubSub topic described in this thread and topics, is intended for use on any channel you obtain a scoped oAuth key for:
So
You’ll need a relevant Access Key from the channel owner.
The redemptions that raise a message in chat do broadcast in the clear/publically over TMI (Twitch Messaging Interface) because they raise a PRIVMSG with the data and chat message attached. (Basically the same as a (re)sub notification in chat, not all resubs appear only those that are actually shared for example).
Not all custom redemptions (or built in ones) will raise a message over TMI. So the PubSub topic covers custom redemptions currently.
That’s exactly what I meant by “own channel”, a token of the channel owner. I also mentioned messages received through IRC, unfortunately those doesn’t contain all necessary information (like reward name/number of points redeemed) for properly displaying it (unlike (re)sub messages which have a convenient system-msg tag). That’s why I was asking if there could be any way to retrieve that information currently or in the future.
I’m trying to create a system where my viewers can interact with the stream directly. The first option was to create my own points system, but using the Channel Points system would be way better.
The thing is, I need to be able to put some rewards in timeout so my viewers don’t spam them. As there is no way of setting that up in the current Channel Points system, what I would love to have is a way of rejecting a reward using the API. That way I could store the rewards’ information locally in my application, and see if it is in timeout or not, and then reject or accept the reward automatically.
I know how I would do it with programming as a third party, but it’s not something Twitch directly supports first party, so should be flagged on the uservoice