Webhook subscription creation returns HTTP 200 and subscription ID, but subsequent GET listings omit it

[prochatgg]

Describe the bug

Creating a chat.message.sent webhook subscription returns HTTP 200 and a subscription ID without an event error. However, subsequent filtered and unfiltered subscription listings using the same app access token do not contain that subscription.

This affects ProChat, a multistream chat application. Users have reported missing Kick chat messages, and our production logs show repeated subscription creation-success/verification-failure sequences across multiple channels.

To Reproduce

We reproduced this with a standalone Node.js script on our production host, outside our application's reconciliation code.

1. Use an existing, unexpired app access token.

2. Send:

   POST https://api.kick.com/public/v1/events/subscriptions
   Authorization: Bearer <APP_ACCESS_TOKEN>
   Content-Type: application/json
   
   {
       "broadcaster_user_id": 19281184,
       "method": "webhook",
       "events": [
           { "name": "chat.message.sent", "version": 1 }
       ]
   }

3. At 2026-09-11T00:13:15.739Z, the request returned HTTP 200. The returned event result contained:

   • Event: chat.message.sent
   • Version: 1
   • Subscription ID: 01M234CHGVT0W37Y6NDXXENH06
   • No event error

4. Using the exact same token, query both endpoints immediately and approximately 2, 10, and 30 seconds after creation:

   GET https://api.kick.com/public/v1/events/subscriptions?broadcaster_user_id=19281184
   GET https://api.kick.com/public/v1/events/subscriptions

5. Observe:

   Time after creation	Filtered GET	Unfiltered GET
   Immediately	HTTP 200; empty data array	HTTP 200; 2,420 subscriptions; no matching ID or broadcaster
   ~2 seconds	HTTP 200; empty data array	HTTP 200; 2,420 subscriptions; no matching ID or broadcaster
   ~10 seconds	HTTP 200; empty data array	HTTP 200; 2,420 subscriptions; no matching ID or broadcaster
   ~30 seconds	HTTP 200; empty data array	HTTP 200; 2,420 subscriptions; no matching ID or broadcaster

The final unfiltered response was recorded at 2026-09-11T00:13:46.269Z, approximately 30.5 seconds after creation.

All listing responses contained an actual data array. We checked the unfiltered results against both the returned subscription ID and the requested broadcaster ID.

Expected behavior

A successfully created subscription should appear in subsequent subscription listings.

If creation is prevented by an application limit, permission requirement, or another restriction, the creation response should indicate that failure. If listing visibility is delayed, please clarify the expected delay.

Screenshots

Not applicable; this was reproduced through direct server-side API requests. Timestamped diagnostic output is available.

Desktop (please complete the following information):

• OS: Ubuntu
• Runtime: Node.js
• Browser: Not applicable; server-side requests using Node.js fetch
• OS and Node.js versions: Not captured in the diagnostic output

Additional context

• Kick Technical Support directed us to report this here.
• The diagnostic made one subscription POST, followed by eight GET requests. It issued no DELETE requests and did not refresh the token.
• Our production application remained running during the diagnostic, so concurrent application activity has not been conclusively ruled out.
• Earlier application logs showed this pattern recurring over several hours and across many broadcasters.
• Our integration requires confirmed webhook subscriptions before activating webhook chat, so failed verification can block chat startup.
• The unchanged count of 2,420 subscriptions is an observation, not proof of a subscription limit.

Could the API team trace subscription 01M234CHGVT0W37Y6NDXXENH06 and determine whether it was persisted, subsequently removed, or omitted from listing responses?

I can provide the developer application's client ID privately if needed.

[prochatgg]

This may be related to #245, which reported successful subscription creation followed by empty GET listings. Our reproduction confirms the returned subscription ID remains absent from both filtered and unfiltered listings through 30.5 seconds. Could this be a recurrence of the synchronization latency discussed there? What visibility delay should clients currently expect?