# EventSub managing dropped subscriptions and token changes **URL:** \ **Category:** API\ **Created:** [July 30, 2025, 4:10am UTC](https://discuss.dev.twitch.com/t/eventsub-managing-dropped-subscriptions-and-token-changes/64089 "2025-07-30T04:10:32Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Taw](https://avatars.discourse-cdn.com/v4/letter/t/cab0a1/32.png) [@Taw](https://discuss.dev.twitch.com/u/Taw)\ **Post date:** [July 30, 2025, 4:10am UTC](https://discuss.dev.twitch.com/t/eventsub-managing-dropped-subscriptions-and-token-changes/64089/1 "2025-07-30T04:10:32Z")
I’m working on getting EventSub up and running via webhooks, and I have a few questions that I don’t see answers to in the docs. 1. If my server fails to give a 2XX in a timely manner, Twitch will revoke the subscription with `notification_failures_exceeded`. But if this happens because my server goes down, the revocation message isn’t exactly helpful. Is there a way to know about the revocation other than just fetching the list of current subscriptions and having to deduce which ones don’t show up? 2. I know Twitch will revoke with `authorization_revoked` if a user revokes the auth token or changes password, but is that also true if the user simply authorizes a new auth token for my app with different scopes? I assume I have to re-subscribe to the desired message types with the new token, right? 3. I understand the load-balancing and distributed processing benefits of conduits, but are they also useful for not having to manually re-subscribe to every event type any time my server goes down and comes back online? I had assumed it would allow me to just reconnect to the conduit and automatically have all my subscriptions ready to go. However, I don’t actually see that described in the docs, so I think I must be mistaken. Can someone clarify how that works? Do I always have to re-sub to every subscription for every user every time? Thanks for the help! ---
**Author:** ![BarryCarlyon](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/barrycarlyon/32/253_2.png) [@BarryCarlyon](https://discuss.dev.twitch.com/u/BarryCarlyon)\ **Post date:** [July 30, 2025, 10:50am UTC](https://discuss.dev.twitch.com/t/eventsub-managing-dropped-subscriptions-and-token-changes/64089/2 "2025-07-30T10:50:17Z")
> [@Taw](#): > > If my server fails to give a 2XX in a timely manner, Twitch will revoke the subscription with `notification_failures_exceeded`. But if this happens because my server goes down, the revocation message isn’t exactly helpful. Is there a way to know about the revocation other than just fetching the list of current subscriptions and having to deduce which ones don’t show up? If your server is down then no, becuase your server was down. So are “your service restart” you need/should sanity check your subscriptions. > [@Taw](#): > > is that also true if the user simply authorizes a new auth token for my app with different scopes? I assume I have to re-subscribe to the desired message types with the new token, right? No. Becuase a user prior authed access between the clientID and a user. Generating a new token just generates a new token which may add _more_ scopes between the clientID and the user, but won’t remove scopes that the new token doesn’t have. So: User auths with a/b/c User later auths with b/d/e You have a/b/c/d/e for the purpose of eventsub. (when in webhooks/conduit land) Given here you are on about webhooks, your app access token is used to create subscriptions and Twitch checks the full list of scopes that were granted between clientID and the user, not the “most recent token” when checking if your clientID can subscribe to a given topic/type. > [@Taw](#): > > but are they also useful for not having to manually re-subscribe to every event type any time my server goes down and comes back online Not for webhooks no, if you only have one callback. Conduits doens’t really give you any subscription benefits here. (sure the shutdown time might be a little longer, but twitch is generally super liberal before it 'nixes webhook subscriptions so a conduit doesn’t give you much more space/time overall), and even then at “service restart” in a one shard land you should still sanity check your subscriptions are what you want when you reconnect the shard(s). If you only have one callback URL/server, then the benefits of a conduit for webhooks are less then just going straight in the first place. ---
**Author:** ![Taw](https://avatars.discourse-cdn.com/v4/letter/t/cab0a1/32.png) [@Taw](https://discuss.dev.twitch.com/u/Taw)\ **Post date:** [July 30, 2025, 8:02pm UTC](https://discuss.dev.twitch.com/t/eventsub-managing-dropped-subscriptions-and-token-changes/64089/3 "2025-07-30T20:02:56Z")
This is all **very** useful information. > Given here you are on about webhooks, your app access token is used to create subscriptions and Twitch checks the full list of scopes that were granted between clientID and the user, not the “most recent token” when checking if your clientID can subscribe to a given topic/type. This makes sense, I keep forgetting that the subscriptions themselves are operating at the application token level not the user token level. However… > Generating a new token just generates a new token which may add _more_ scopes between the clientID and the user, but won’t remove scopes that the new token doesn’t have. This is not at all what I expected…So in order to get a new user token with fewer scopes, you have to actively revoke the current token before authorizing the new one? This brings up further questions that I have about tokens: - I was under the assumption that you could only have one active user token at a time for a given user. If they re-auth, they get a new token and the old token doesn’t work anymore. Is that not true? - Does that new token then take on the scopes of the old token PLUS the scopes requested for the new token? - If that assumption is false and the user can actually have multiple active user tokens for my app at once, do I have to do anything special to manage those old tokens or can I just ignore them and use the newest token? - Lastly, is there a place in the docs that describes all of this that I somehow missed? If not how are we supposed to know that it works this way? Or is this standard OAuth behavior that I’m just not well aware of? > If you only have one callback URL/server, then the benefits of a conduit for webhooks are less then just going straight in the first place. This is great to know. I’ll continue without conduits then until I actually have a use for the sharding and load balancing features. I just wish there was an easier way than having to send each subscription one by one. When there are a lot of subscriptions to make, such as for a multi-channel chat bot using webhooks for chat messages, it takes ages to “rejoin” all the channels on startup if the downtime was long enough to drop subscriptions. Thank you for the answers! ---
**Author:** ![BarryCarlyon](https://d3ovvz0v2ajtpu.cloudfront.net/user_avatar/discuss.dev.twitch.com/barrycarlyon/32/253_2.png) [@BarryCarlyon](https://discuss.dev.twitch.com/u/BarryCarlyon)\ **Post date:** [July 30, 2025, 11:09pm UTC](https://discuss.dev.twitch.com/t/eventsub-managing-dropped-subscriptions-and-token-changes/64089/4 "2025-07-30T23:09:59Z")
> [@Taw](#): > > This is not at all what I expected…So in order to get a new user token with fewer scopes, you have to actively revoke the current token before authorizing the new one? when you make a new user token, the new token has the scopes on it that you requested. But the app access token for the clientID can still create eventsub types for the full list of scopes. > [@Taw](#): > > I was under the assumption that you could only have one active user token at a time for a given user. If they re-auth, they get a new token and the old token doesn’t work anymore. Is that not true? That is incorrect. You can have 50 active access tokens (last I checked) But again, we are predominately talking about how eventsub works here. > [@Taw](#): > > Does that new token then take on the scopes of the old token PLUS the scopes requested for the new token? no it only has the scopes that was in the request to generate the token. > [@Taw](#): > > If that assumption is false and the user can actually have multiple active user tokens for my app at once, do I have to do anything special to manage those old tokens or can I just ignore them and use the newest token? For eventsub webhooks, you don’t use the user token. If you are making API calls with the user token then retain the relevant token. > [@Taw](#): > > Lastly, is there a place in the docs that describes all of this that I somehow missed? If not how are we supposed to know that it works this way? Or is this standard OAuth behavior that I’m just not well aware of? To my knowledge this is standard oAuth behaviour. A Generated user token have the scopes on it that were asked for during the request. ---
**Author:** ![system](https://d2opxh93rbxzdn.cloudfront.net/original/2X/0/05909729875cce3b53e59d5561c4d23bb14948fc.png) [@system](https://discuss.dev.twitch.com/u/system)\ **Post date:** [August 29, 2025, 11:10pm UTC](https://discuss.dev.twitch.com/t/eventsub-managing-dropped-subscriptions-and-token-changes/64089/5 "2025-08-29T23:10:48Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.