Hey Yoni,
At the moment, there's no way to distinguish with the event whether a subscription was canceled automatically at the end of the period or if it was due to too many retries. In both cases, the event will have `source: null` as expected. This event is not triggered by a direct API request that your code would have just made so it would always have `source: null`.
As mentioned by a user in your StackOverflow question [1], the easiest solution really is to track this on your end. That way when the subscription is canceled you'd be able to confirm in your own database that you had marked it to cancel at the end of the period and then you could log this properly.
Otherwise, another solution is to rely on the latest invoice and it's associated latest failed payment. When you get the event, you'd find the latest invoice for that subscription. You'd then check whether this invoice has been paid successfully or not. If not, you'd look at the latest charge [2] to see when it was created and when it failed and whether there's another attempt [3] scheduled on the invoice. Based on this information, you can then decide whether the subscription was canceled automatically or due to that latest payment.
I definitely agree that it would be easier to have a field on the subscription that said whether it was canceled by your code or by our system and I'll make sure to share it with the engineering team.
Hope this helps!
Remi