is there an official client-initiated way to read live chat (without webhooks)?

[Izmochu]

Hi Kick team 👋,

I’m currently building a local desktop application (Python + local UI) that integrates multiple streaming platforms (Twitch, YouTube, Kick) into a single control panel for streamers.

The application:

• Runs entirely on the user’s machine
• Is only active while the streamer has it open
• Does not run persistently in the background
• Is not a cloud service or SaaS
• Is similar in nature to an OBS plugin or StreamDeck-style desktop tooling

For Twitch, reading live chat is straightforward via client-initiated connections (IRC / WebSocket).
For Kick, I understand that the officially supported way to receive chat messages is via webhook events (chat.message.sent), which works very well for cloud-based services.

However, for desktop / local-first applications, the webhook-only model introduces some structural challenges:

• Webhooks require a publicly reachable backend, even when the app is purely local
• Chat events are delivered even when the local application is offline
• A backend must maintain routing/state to determine whether a local client is currently connected
• This effectively forces desktop tools into a cloud-service architecture, even when they don’t need one

From a desktop tooling perspective, this feels like a mismatch, as the natural model is:

• client-initiated
• scoped to an authenticated user/session
• active only while the application is running
• read-only access to live chat messages

With that context, I wanted to ask:

• Is there any existing (even undocumented) way to read live chat messages via a client-initiated approach (polling, SSE, WebSocket, etc.) intended for local/desktop applications?
• Is such a capability planned or being considered as part of the API’s future direction?
• Or is the webhook-based model intentionally the only supported way to consume chat messages by design?

I’ve reviewed the KickDevDocs and roadmap, and I see many chat-related improvements focused on webhook payloads, but nothing that seems to cover local/desktop consumption of live chat.

The goal here is mainly to understand the intended direction, before resorting to non-official approaches that emulate the web frontend.

Thanks a lot for the work you’re doing on the API, and for any clarification you can share 🙏

[MarshallBruce8702]

Hi, I have the same architectural requirement.

I'm developing a native Windows OBS Studio plugin that aggregates Twitch, YouTube, TikTok and Kick chat locally inside OBS.

The application is desktop/local-first and only needs to receive chat while OBS is running.

Our current Kick integration can passively observe the normal Kick web chat behavior, which works for many viewer/random channels. However, we have found a reproducible case where the broadcaster's own channel does not establish the same usable chat subscription, so we do not want to rely on undocumented frontend/Pusher behavior as a workaround.

We investigated migrating the broadcaster connection to the official Kick API. events:subscribe and chat.message.sent appear to provide exactly the data we need, but webhook-only delivery would require us to introduce a permanent public relay/backend solely for a local OBS plugin.

The documented OAuth flow also requires client_secret during authorization-code exchange and refresh, which we do not want to embed in a publicly distributed desktop binary.

Could the Kick team clarify whether there is, or is planned to be, an officially supported architecture for native/public desktop clients that provides:

broadcaster OAuth without embedding a confidential client secret; and
client-initiated reception of chat.message.sent through WebSocket, SSE, long polling, or another supported mechanism without a permanent webhook backend?

If webhook + developer-controlled backend is intentionally the required architecture for desktop applications as well, confirmation of that would also resolve our design decision.

We specifically want to remain within documented/supported Kick mechanisms rather than emulate or synthesize the website's internal chat subscription.

Thank you.

[DanAsker]

Please see #20 and comment there to help push the websocket development along