The kicks.gifted webhook event does not appear to be delivered to a correctly registered subscription endpoint, despite the subscription itself being created successfully and the app holding the required kicks:read scope. Other event types registered in the same batch (channel.followed, channel.subscription.new, channel.subscription.renewal, channel.subscription.gifts) all deliver correctly to the identical endpoint.
Environment
Official Kick public API, webhook delivery method (POST /public/v1/events/subscriptions)
OAuth scopes requested: chat:write user:read moderation:ban events:subscribe kicks:read
Steps to reproduce
Register a webhook subscription batch including kicks.gifted (v1) alongside channel.followed, channel.subscription.new, channel.subscription.renewal, channel.subscription.gifts (all v1), pointed at a working, publicly reachable HTTPS endpoint.
Confirm registration success — the response includes a valid subscription_id for every event, including kicks.gifted (see below).
Trigger real events naturally:
A follow → webhook delivered correctly.
A sub/resub → webhook delivered correctly.
A real Kicks gift (tested organically on two separate occasions, not synthetic) → no webhook request received at all.
Expected behavior
A kicks.gifted webhook request should be sent to the registered endpoint when a viewer gifts Kicks, the same way channel.followed and the subscription events are delivered.
Actual behavior
No HTTP request of any kind arrives at the endpoint when a real Kicks gift occurs. This isn't a signature-verification failure or a parsing issue on our end — the endpoint receives literally zero incoming requests at the time of the gift, while it correctly receives and processes requests for every other subscribed event type in the exact same batch, sent to the exact same URL.
Additional troubleshooting already done
To rule out the issue being specific to our webhook endpoint or infrastructure, we also attempted to catch this event via Kick's real-time Pusher-based WebSocket connection (the same one used for chat):
The standard chatroom channel (chatrooms..v2) — used successfully for chat messages, replies, message deletions, and even an undocumented SubscriptionEvent. No Kicks-gift-related event ever appears here.
Several broadcaster/channel-level channel name guesses (channel.<broadcaster_user_id>, channel.<channel_id>, channel.<chatroom_id>, and the channels. plural variants of each) — all subscribed successfully at the Pusher protocol level (pusher_internal:subscription_succeeded), but none ever received any traffic related to a Kicks gift.
Registered subscription response
{
"data": [
{"subscription_id": "01KZP1ZDGS4EBJVBMFJDEMXWYD", "name": "channel.followed", "version": 1},
{"subscription_id": "01KZP1ZE4RQZKKJ0CBX90PFDZQ", "name": "channel.subscription.new", "version": 1},
{"subscription_id": "01KZP1ZEBTCJ7DVAMVYV62CP0Q", "name": "channel.subscription.renewal", "version": 1},
{"subscription_id": "01KZP1ZEP8QQYSNYJPBB1WAFYR", "name": "channel.subscription.gifts", "version": 1},
{"subscription_id": "01KZRJ9EZ0RVJ03YV12X27A8PB", "name": "kicks.gifted", "version": 1}
],
"message": "OK"
}
Question:
Is kicks.gifted fully live in production for third-party apps, or is it still gated to specific partners? If it requires something beyond what's documented (a different scope, a private/authenticated Pusher channel, an allowlist, etc.), it would be great to have that documented — the current public docs suggest this should work out of the box with the kicks:read scope and a standard webhook subscription.
The kicks.gifted webhook event does not appear to be delivered to a correctly registered subscription endpoint, despite the subscription itself being created successfully and the app holding the required kicks:read scope. Other event types registered in the same batch (channel.followed, channel.subscription.new, channel.subscription.renewal, channel.subscription.gifts) all deliver correctly to the identical endpoint.
Environment
Official Kick public API, webhook delivery method (POST /public/v1/events/subscriptions)
OAuth scopes requested: chat:write user:read moderation:ban events:subscribe kicks:read
Steps to reproduce
Register a webhook subscription batch including kicks.gifted (v1) alongside channel.followed, channel.subscription.new, channel.subscription.renewal, channel.subscription.gifts (all v1), pointed at a working, publicly reachable HTTPS endpoint.
Confirm registration success — the response includes a valid subscription_id for every event, including kicks.gifted (see below).
Trigger real events naturally:
A follow → webhook delivered correctly.
A sub/resub → webhook delivered correctly.
A real Kicks gift (tested organically on two separate occasions, not synthetic) → no webhook request received at all.
Expected behavior
A kicks.gifted webhook request should be sent to the registered endpoint when a viewer gifts Kicks, the same way channel.followed and the subscription events are delivered.
Actual behavior
No HTTP request of any kind arrives at the endpoint when a real Kicks gift occurs. This isn't a signature-verification failure or a parsing issue on our end — the endpoint receives literally zero incoming requests at the time of the gift, while it correctly receives and processes requests for every other subscribed event type in the exact same batch, sent to the exact same URL.
Additional troubleshooting already done
To rule out the issue being specific to our webhook endpoint or infrastructure, we also attempted to catch this event via Kick's real-time Pusher-based WebSocket connection (the same one used for chat):
The standard chatroom channel (chatrooms..v2) — used successfully for chat messages, replies, message deletions, and even an undocumented SubscriptionEvent. No Kicks-gift-related event ever appears here.
Several broadcaster/channel-level channel name guesses (channel.<broadcaster_user_id>, channel.<channel_id>, channel.<chatroom_id>, and the channels. plural variants of each) — all subscribed successfully at the Pusher protocol level (pusher_internal:subscription_succeeded), but none ever received any traffic related to a Kicks gift.
Registered subscription response
{
"data": [
{"subscription_id": "01KZP1ZDGS4EBJVBMFJDEMXWYD", "name": "channel.followed", "version": 1},
{"subscription_id": "01KZP1ZE4RQZKKJ0CBX90PFDZQ", "name": "channel.subscription.new", "version": 1},
{"subscription_id": "01KZP1ZEBTCJ7DVAMVYV62CP0Q", "name": "channel.subscription.renewal", "version": 1},
{"subscription_id": "01KZP1ZEP8QQYSNYJPBB1WAFYR", "name": "channel.subscription.gifts", "version": 1},
{"subscription_id": "01KZRJ9EZ0RVJ03YV12X27A8PB", "name": "kicks.gifted", "version": 1}
],
"message": "OK"
}
Question:
Is kicks.gifted fully live in production for third-party apps, or is it still gated to specific partners? If it requires something beyond what's documented (a different scope, a private/authenticated Pusher channel, an allowlist, etc.), it would be great to have that documented — the current public docs suggest this should work out of the box with the kicks:read scope and a standard webhook subscription.