The resub chat message and sub/unsub events are indeed not sufficient in cases where an application needs to know accurately about subscriptions because of the overlap mentioned below.

This can be critical for cases when subscriber counts and/or timing is important. For example, an application that hands out (re)subscriber rewards during a limited time, or gathering stream analytics with up-to-the-minute accuracy.

With the existing events, a returning subscriber, or someone who upgrades their sub tier, would emit a channel.subscription event, but also have a chance to send a resub message and therefore also emit channel.subscription.message. There is no easy way to identify whether a subscription.message event was already emitted as a subscription event. This would result in the sub being double counted, and if the application gives any rewards to the subscriber, cause that to happen twice.

A resub with existing automatic payment would not emit any information if the person does not send a resub message for any reason.

The resub message is also sent at a time of the user's choosing (while the subscription message is always at the time the sub actually begins). This can be potentially days or weeks after the actual resub took place. This makes it hard to match up resub messages with any sub messages received previously, as it could be anywhere within the previous month.

Reviving discussion here. I recently have been creating an application that tracks subscriptions and found that there is occasionally overlap between channel.subscription and channel.subscription.message when a subscriber continues their subscription after a break (thus new billing).

If I count each of these events then my subscription count is now wrong because this single subscription counts for both events. There is no common identifier between the two either, which means there is no elegant solution to have this occurrence count as a single subscription.

If we had a resub event, I would be able to use that instead of channel.subscription.message and presumably avoid this issue.

Having the resubs on the EventSub is something that is really missing, I'm trying to build an application, but I can't test if the events are working correctly since PubSub doesn't offer a way to manually trigger an event, and can't complete my application without the resub events, since if I use chat messages some subs will get missed, and with the application being used as an interaction with the stream, if someone choose to not send a message than their subscription won't be counted by the application, ending with the viewer having a lost opportunity.

I need RESUB event because I have a goal bar that shows the number resubs of the day, this information would be incorrect if I do not know when someone RESUB without sending the message in the chat. This event exists in the webhook and in PubSub along with the subscription event, it should be included in the EventSub so as not to break the features that people built on top of it.

Agreed, EventSub is feeling like a second class system without this information provided. I don't see a need for a separate subscription item for resubs vs. first time subs; I think the existing item should have resubs and tenure information included.

> I’m not clear on the use case for this. It seems like with a resub chat message notification and subscribe/unsubscribe events you should have the data you need.

We need to track people whom resub but don't notify in chat.
Generally for the purpose of tenure
Or missing unsub events.

Please add Resubs to EventSub... I'd like to eventually drop use of PubSub but cannot do so until EventSub has feature parity with PubSub.

With all the events (sub/resub/subgift ...) in EventSub it would be possible to update my application to just invoke lambda functions instead of having to keep a machine on all the time connected to chat.

Yes. Having this would be great! No need to use PubSub then.

Please include tenure data in the payload (current streak, total months)

Hi Barry, could you provide more details on what you'd use this for and could you elaborate on the difference between this and a chat notification event? Thanks!

This would make implementations a lot easier!

Having resub notifications in EventSub really would make life easier, and negate the need to use PubSub alongside it.

Definitely could use this asap!