#ibgoldbergs
1 messages · Page 1 of 1 (latest)
Yeah definitely. You can listen to the customer.subscription.updated event. That can get triggered for a number of reasons so you can check the event's previous_attributes to see what exactly was changed
The Customer Portal sets either cancel_at or cancel_at_period_end, I forget which
But it will consistently use one of them, so you can check whether that property was changed and use that to know that the user's subscription will cancel at the period end
What kind of limit? We don't limit the number of them if that is what you are asking, we'll send you whatever events you are subscribed to as often as they are triggered
oh thats all i was wondering. It just seems expensive to sometimes accept like "all subscription updated events" instead of just the ones you need
Gotcha, yeah I get how that feels wasteful to do a lot of no-ops here. I can put in feedback that it might be helpful to have an event specifically for this kind of update but at the moment processing all of these events would be the best way to see this via webhooks.
cool thanks for the insights on using that