Hi - I am trying to debug some issues we’re having with our application, where our bot is not joining some streams. I’m noticing now that it seems we’re unable to create any more webhooks against our application ID for users, and getting an error of “subscription limit exceeded”.
I checked the Managing Subscriptions | Twitch Developers and looks like we’re at the 10k mark - is there a process to increase this value?
Get authentication from the broadcaster(s) you are reading the data of.
Which you should be for a bot
Under expected operation you get channel:bot from the broadcaster, as at scale you probably should be on a conduit IMO.
assuming here you are using chat type topics/types. Which need authentication from both entities.
Hey thanks for the quick reply.
Sorry I don’t think I understand, might just me being dense while trying to figure it out. We do get the users permissions for various aspects on their channel, and then we create the webhooks against our application ID so that we can respond/react to various events (chat messages, rewards etc). We moved from the IRC channel / websockets integration to the webhooks one as we were told the former was being depreciated.
From what I understand, (or what I pertain to understand from the documentation) is that an application can have at most 10k of these unique events, of which we have now exceeded according to the link I previously shared.
So yes, we get the authentication for the user to have the required permissions. I potentially mis-worded when I said our bot ‘joining’ the streams, because we’re not actually joining, just listening to events via the webhooks - which aren’t being created due to the ‘subscription limit exceeded’ message.
I assume the ‘fix’ for this is to take our webhook functionality into conduits?
No
it’s 10k cost 1’s
If you are authenticated they are cost 0. (So chat topics are always cost 0)
Conduits and webhooks share the same authentication structure.
if your cost total is > the max total. From perhaps users revoking access, which changes say stream.online from cost 0 to cost 1, and you don’t clean up.
Then you are blocked from making new subscriptions until you are back below the limit
Right I see - we are passing through the users bearer token instead of our client, but from what you’re saying (and if I understand), I instead need to check our webhooks, see if it is causing a ‘cost’ and then revoke those accordingly. Then we’ll be able to create new ones without a cost, provided we’re using their access/bearer tokens accordingly.
Shouldn’t be on webhooks as webhooks needs app access tokens. A user bearer token will not work.
You can also use the auth revoke type to monitor for disconnects and/or revoke payloads on cost 0/scope require types.
Great thank you for that, it clears up what I was doing previously and now I seem to have got it back to normal. Cheers!