#windlepoons-events
1 messages · Page 1 of 1 (latest)
One action can certainly set off multiple events depending on what it touches. Not immediately sure on the Invoice example. I can see if we find a doc but if you test it will definitely show the proper behavior
I'm mainly looking to accurately reflect current Stripe state in our cache (to avoid Stripe API limits). And I want to make sure I'm listening for the correct minimal amount of events to keep invoice/subscription/customer up to date.
If the parent event for a bunch of invoice changes is invoice.updated, such that its the only one I need to listen for... I'd prefer to listen just for that one instead of push more changes into our cache that aren't needed.
I see what you are saying. So for here you want to know about how to figure this out in general or are you specifically asking about the paid situation?
In general
That would be more of a case-by-case basis I would think.
So in this case you do actually get paid and updated.
Does invoice.upcoming also trigger invoice.updated?
It'd be great if there was an event hierarchy diagram or something that made it more clear what triggers what, and what 'parent' events will be triggered by more specific things.
This page is pretty good at laying out subscription events in general https://stripe.com/docs/billing/subscriptions/overview
Not a diagram but pretty comrehensive
It misses a lot of detail though
An invoice.paid event is sent, indicating that the invoice was successfully paid.
It doesn't mention it also sends invoice.updated
Nor is there a list of what other invoice events will also trigger invoice.updated. I assume any attribute change on the invoice trigger invoice.updated, but its a little odd to have to try and reverse engineer Stripe to know for sure, and that seems like a brittle implementation detail if it isn't documented behavior.
Yeah I see what you mean. I guess that doc is more for the canonical events you should look at in each of those cases. Is there a reason you are trying to reduce the number of event types you are listening for? The differentiated event types can be very helpful
Mainly to try and avoid writing the new object to our cache more times than needed.