Channel Point Redemption Queues on Twitch and KICK: Statuses, Ownership, and Backlog Rules

A free reward still makes a promise

Picture a reward called 'Name the next enemy' at 200 points (an example, not a real channel). A raid lands, fifty viewers redeem it inside a minute, and each believes their name is about to be read out. The points were free, but viewers earned them, and a redemption that quietly vanishes feels like a lost wallet.

Without a queue model, mods fall into one of two habits. They mark everything done to clear the list, or they let it grow until the stream ends with hundreds of unresolved rows. Both come from the same gap: no shared definition of each state and no agreement on who may move a redemption along.

This post covers free redemptions that trigger on-stream moments. The subject is plumbing, not pricing.

Two vocabularies, one working model

Twitch's API reference lists three redemption statuses: UNFULFILLED, FULFILLED, and CANCELED. A new redemption starts UNFULFILLED, and the update endpoint accepts only FULFILLED or CANCELED as the value you set. KICK's developer docs list pending, accepted, and rejected, and the KICK help center describes the same actions in dashboard words: mark a request Complete, or Reject it.

Neither platform has an 'I am doing this right now' state, and that gap is where double-handling starts.

• Waiting: Twitch UNFULFILLED, KICK pending. Nobody has resolved it. This is the only state the Twitch update endpoint will act on.
• Working: no platform equivalent. A mod claims it in the mod channel, or a tool flags it in its own storage. It means 'someone is mid-task, hands off'.
• Done: Twitch FULFILLED, KICK accepted (Complete in the dashboard). The viewer got what they redeemed for.
• Returned: Twitch CANCELED, KICK rejected. The points go back to the viewer.

Treat done and returned as one-way doors

Twitch's reference says you may update a redemption only if its status is UNFULFILLED. So once a redemption is fulfilled or canceled, the documented endpoint offers no path back. KICK's docs describe no undo either. Plan as if Complete is permanent.

Tools can follow these states through events. Twitch lists EventSub types for redemption add and update; the samples show unfulfilled on add and fulfilled-or-canceled on update. KICK documents a channel.reward.redemption.updated event at version 1, described as fired when a reward is redeemed. Its sample payload carries status and user_input and shows a rejected redemption, so a handler should expect all three statuses on that one event. History is short, too: Twitch notes that canceled and fulfilled redemptions come back from the list endpoint for only a few days, so keep your own log.

Skip the queue only when nobody needs to say no

Twitch's should_redemptions_skip_request_queue flag makes a redemption FULFILLED the moment it is redeemed; when it is false, the redemption is UNFULFILLED and follows the normal queue. KICK's reward API has a field with the same name, though the page does not explain it in prose, so confirm its behavior with a test redemption before relying on it.

The cost of skipping is easy to miss. A redemption that is born FULFILLED is not UNFULFILLED, and by Twitch's own update rule the endpoint will not touch it. By that rule, a skipped redemption has no refund route through the API. You trade the ability to say no for a shorter list.

A workable rule of thumb, which is judgment and not platform policy: skip the queue only when the effect is automatic, harmless, and fine to happen even if the viewer regrets it. A 'drink some water' reminder qualifies. Text input, scene changes, and anything a mod might veto should keep the queue.

The ownership trap

Twitch's reference repeats the rule: the app used to create a reward is the only app that may update it, delete it, read its redemptions, or update a redemption's status. The 403 text for redemption updates says the Client-Id header must match the client ID used to create the custom reward. KICK's docs carry the same limit for update and delete, saying that only the app that created the reward can do it.

The consequence runs both directions. A reward you made by hand in the dashboard was not created by your bot, so by the docs' rule the bot is locked out of managing it. Twitch's reward list even has an only_manageable_rewards filter that returns just the rewards the calling client ID may manage. On KICK, the redemptions list returns a can_manage flag on each reward, and the accept and reject docs show a failure reason named NOT_OWNED. Whether the dashboard queue treats app-created rewards differently is not answered in the docs, so test it.

Twitch requires reward titles to be unique per broadcaster (45 characters max) and answers duplicates with a 400, so a bot cannot take over by recreating a same-named reward. Swapping bots strands the old bot's rewards for the same reason.

Delete deserves its own warning. Twitch's Delete Custom Reward text says UNFULFILLED redemptions are marked FULFILLED when their reward is deleted. Deleting a reward with a full queue wipes it as 'done', with no refunds. Pause first, clear the queue by hand, delete last.

• Keep a one-line ledger per reward: name, dashboard or which app created it, who may act.
• One owner per reward. If a bot and a mod can both resolve it, the working state is mandatory.
• Never delete a reward that still has waiting items.

Who may act, and what a refund actually means

On KICK, the help center says moderators can complete, reject, and pause from the Reward Request Queue widget in the Moderator Dashboard. On Twitch, the API path needs a user access token with the channel:manage:redemptions scope, and broadcaster_id must match the user in the token. That describes the broadcaster's authorization; I could not load Twitch's help article, so confirm what your Twitch mods can do from their own view.

Refunds are what viewers care about. Twitch's docs say setting a redemption to CANCELED refunds the user's channel points. KICK's help center says rejecting a request refunds the points; its API page for rejecting does not repeat that, so verify with a test. Complete is the keep-the-points outcome on both.

That gives mods a clear rule: return early, and never mark something done that did not happen. A returned redemption costs the viewer only time. A falsely completed one cannot be repaired.

Put the rule in the reward description, for example: 'If I can't do this, you get your points back.'

Text input is the risky kind of redemption

Both platforms let a reward ask the viewer for text. On Twitch, the prompt is capped at 200 characters and meant for rewards that require input. KICK's help center says responses are shown in chat, and warns streamers not to request or provide personal information. If answers are public the instant they are submitted, review cannot happen first, so prompt wording and chat filters do the early work.

Write narrow prompts: 'Name one boss strategy' invites a short, safe answer, and 'tell me anything' invites everything. Agree return rules in advance: links, personal details, targeting a named person, and anything you would not read aloud all get returned.

If your channel also runs paid uploads or TTS, that review list is a different queue from the platform's reward queue. Name them differently in mod notes ('uploads' versus 'rewards') so 'approve' keeps one meaning, and so nobody completes a reward when they meant to approve an upload.

Caps, pause, and draining a spammed queue

Twitch lets you set a maximum per stream, a maximum per user per stream, and a global cooldown, each applied only when its enabled flag is true. The cooldown minimum is 1 second, though 60 is the minimum for it to show in the Twitch interface. The KICK help page has no cooldown details and its reward API fields list no such limits, so I will not guess; treat pausing as the main brake there.

Pausing is the circuit breaker. With Twitch's is_paused, viewers can't redeem the reward, and KICK's help center says redemptions can be paused, by mods too. Expect pause to stop new arrivals, not resolve what is waiting; check on a test reward.

The drain rules below are my judgment, not platform behavior.

• Honor oldest first, except duplicates. If thirty people asked for the same thing, honor one and return the other twenty-nine with a chat note.
• Pace by scene. Pick a number you can do gracefully, such as three per break, and return the overflow instead of rushing.
• Batch only what you know. Twitch accepts up to 50 redemption IDs per update call for one reward, and KICK accepts and rejects up to 25 per request and returns only the failures. Batch returns freely, and batch completes only what you actually did.
• Sweep at the end of every stream, returning whatever you did not honor.

Edge cases to decide before they happen

Stream goes offline with items waiting. Twitch reports the per-stream redemption count as null when the broadcaster is not live. I did not verify whether a reward stays redeemable offline. Pick a policy: sweep at the end, or carry items over.

Reward disabled mid-queue. Twitch says viewers see only enabled rewards but not what happens to waiting redemptions, so clear the queue first, as with deletion.

Bot offline. Events can be missed, so on startup read each reward's waiting list. Twitch's list endpoint takes a status filter, and KICK's defaults to pending.

Double-complete. Two mods click on the same row. On Twitch the second update gets a 404 because the status is no longer UNFULFILLED; on KICK the response lists the redemptions that failed. The record is fine; the danger is both mods performing the on-stream action.

Wrong owner. A Twitch 403 about the client ID, or can_manage false or NOT_OWNED on KICK, means the tool is not the creator; let a human act in the dashboard.

A test plan with a friend account

Use a second account with enough points to redeem. Make a test reward as cheap as the platform allows (Twitch's minimum cost is 1 point) and write down what you see. Where a result differs from this post, trust the result.

• Redeem, then return it. Does the friend's balance go back up on both platforms?
• Turn on skip-queue for one test reward. Does it land as done? Can you still return it?
• Pause the reward. Can the friend still redeem? What happens to items already waiting?
• Add a text prompt. On KICK, does the text show in public chat at once?
• Have two mods click the same row at the same moment. What does each see?
• Restart your bot mid-queue and confirm it reconciles the waiting list.
• Try to act on a dashboard-made reward with your tool. Record the exact error or flag.
• On Twitch, delete a test reward that has a waiting item, and see where the item ends up.