#susnet-subscriptionwebhooks
tropic rune
the best option is to only use the Checkout event, you shouldn't need to use the others.
So for example you listen to the checkout.session.completed event and then retrieve the related subscription object it references, and you do all your database creation and reconciliation at that point.
You could also ignore customer.subscription.updated if say the latest_invoice of the referenced subscription has billing_reason:"subscription_create" since you will handle that case in your Checkout handler
orchid forum
But when I will listen only on checkout.session.completed I wont have latest data when subscription will be updated outside of checkout flow
tropic rune
yep but you can listen to customer.subscription.updated and ignore it in cases where the update event is happening at the same time of creation, as described in my second paragraph
for example if you recieve that event and the created field of the event.data.object (the subscription) is in the last hour and you retrieve the latest_invoice of the subscription and it has billing_reason:"subscription_create" then you can choose to ignore that since it's not a 'real' update and your Checkout handler will create the records; you only care about that .updated event on existing subscriptions
it's not perfect unfortunately, there's no perfect solution here
orchid forum
And then Can I ignore the checkout.session.completed? as I am updating user account status on invoice.paid and I am just syncing subscription data for displaying it in user account and eliminate the need for stripe request every time
I thought invoice.paid will be best as its get fired even if its recurring automatic charge
tropic rune
yep another good option is to only ever use invoice.paid. Again, make sure to make use of the billing_reason field https://stripe.com/docs/api/invoices/object#invoice_object-billing_reason
orchid forum
Okay, thank you for help
solemn crater
👋 taking over for my colleague. Let me know if there's any follow-up Qs I can answer!
orchid forum
In the invoice.paid I am currently not looking into billing_reason instead I am checking if there is SubscriptionId field to determine if invoice is associated with a subscription, then I am retrieving that subscription data and based on that I am assigning my users a plan. Is this enough or should I still check billing_reason and skip if its manual?
solemn crater
as @tropic rune explained, billing_reason helps understanding why the invoice has been created
it could be because of subscription_cycle meaning it's a renewal, subscription_create meaning the start of the subscription, subscription_update meaning that the plan/prices have been updated or something else (and you will get what changed in the event with previous_attributes) and so on