Intermittent/Stalled Webhook Delivery for Chat Messages

[pavelnaut]

Describe the bug
My application is subscribed to chat.message.sent (and other events), but webhook delivery is borderline non-existent.

• Upon refreshing the webhook in the kick dashboard, I might receive a few chat events successfully.
• Immediately after, delivery stops completely for an extended period.
• Occasionally, another batch of 1-2 events will arrive, followed by silence again.
• Other events (like livestream.status.updated) seem to be affected similarly.

To Reproduce

1. Configure a valid Webhook URL (verified with ngrok and Cloudflare Tunnel) in the Kick Developer Dashboard.
2. Subscribe to chat.message.sent using POST /events/subscriptions (App ID: 01K5HAMBCGRME4TWX6H0RKJ038).
3. Verify subscriptions exist via GET /events/subscriptions (returns 200 OK).
4. Send multiple chat messages in the channel (pavelnaut / User ID: 77140873).
5. Observe that only the first 1-2 webhooks arrive, and subsequent messages generate no traffic to the webhook endpoint. Other times none arrive in the first place.

Expected behavior
I expect to receive a chat.message.sent webhook for every chat message sent in the channel, as my application is well within reasonable volume limits (testing with < 10 messages).

Desktop (please complete the following information):

• OS: Windows 11
• Browser Firefox
• Environment: Python (Flask) with ngrok / cloudflared (tested both)

Additional context
Is there an undocumented rate limit for unverified apps that is too aggressive? The documentation mentions a limit of "1,000 for unverified apps", but I am seeing a hard stop after just a few messages. It feels like a "stuck" state on the dispatch worker.

[spookghetti]

I'm having the same issue with unreliable webhook events with similar low volume testing. Out of 60 chat messages sent in the channel over 6 minutes, I received 16 message events.

• OS: Windows 11
• Browser: None
• Environment: Rust (Dioxus) desktop app and ngrok.

[ash-easygo]

So far it looks like everyone that has reported seem to be using ngrok. We are looking into this now.

[zachingle-easygo]

Hey @pavelnaut @spookghetti,

For production use, we highly recommend not using a tunnelling service as they make it more likely that webhooks would be dropped. You must also consider the rate limits of the free plan for ngrok.

If you guys are finding issues with ngrok as well, there are some nice alternatives found in this list here. I found localtunnel seems to work well.

We'll provide some more updates here as we find out more.

[pavelnaut]

As I described above, this is not ngrok exclusive issue. I have observed the same thing with a new cloudflared connection.

[DanAsker]

Just to add some context - we are using cloudflared as a tunnel and do not experience these issues. We have not tested ngrok

Has the retry limit on delivering a webhook been documented yet around returning a 200? Or a timeout for returning? I wonder if transient latency could be causing the webhook subscription to be cancelled?

[Aeroverra]

Within the last 5 days I had a single hour that recieved and processed 15k+ webhook message events with Cloudflare sitting in front. As far as I can tell I am not having this issue.

Not sure what ngrok is but I would start testing with it and then without it to see if there is a difference.