#splue_webhooks
undone jungleBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1324443301939777568
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
north skiff
Hi 👋
I see two webhooks receiving this event currently. I don't see any pending. What is the URL for your new webhook endpoint?
lusty arrow
to be clear, i registered the event AFTER the original events were sent
also, thank you snufkin for looking into it
north skiff
https://api.accessmembers.com/payments returned a 200 response at 2025-01-02 18:02:30 UTC for this event
lusty arrow
yeah i see that too
is it possible that the dashboard is reporting 200 even if it doesn't reach our endpoint?
is it possible that the original event isn't configured for the endpoint since i registered the event AFTER the original event was created?
north skiff
is it possible that the dashboard is reporting 200 even if it doesn't reach our endpoint?
No, I'm not looking at the Dashboard. I can see the actual HTTP response from your server
is it possible that the original event isn't configured for the endpoint since i registered the event AFTER the original event was created?
Not sure what you mean. The replays of this event ARE hitting your server
lusty arrow
okay i see
so you dont think the following scenario would cause any unexpected behavior?
-
Jan 2 9:00am -> payment success event is triggered
-
Jan 2 10:00am -> payment success event is registered to endpoint
-
Jan 2 10:30am --> payment success event from 9:00am is manually sent via stripe cli
north skiff
Nope. From what I can see that is exactly what you did/are doing and you are receiving the events.
One potential debugging tip you might consider if your server is responding to the webhook request from Stripe but your system doesn't appear to be doing what you expect:
You could try adding some debugging info in the response body. It adds a little bit of latency in your response but it writes the data into the event logs you can see in your dashboard.
lusty arrow
ah okay i see thanks
what does these key/values mean in the event?
"pending_webhooks": 1,
"webhooks_delivered_at": null
undone jungleBOT
lusty arrow
also i think i figured it out...
it's because i was listening for
billing_reason === 'subscription_cycle'
but the event actually has billing_reason === 'subscription_update'
could you also describe in more detail what the difference bewteen tehse are?
https://docs.stripe.com/api/invoices/object#invoice_object-billing_reason
nova magnet
Hi there 👋 jumping in as my teammate needs to step away soon.
lusty arrow
thanks toby
nova magnet
pending_webhooks contains the number of webhooks that have yet to be successfully delivered:
https://docs.stripe.com/api/events/object#event_object-pending_webhooks
lusty arrow
okay gotcha
and then for update vs cycle?
could update be firing because it's the end of a trial period?
nova magnet
subscription_cycle: A subscription advanced into a new period.
subscription_update: A subscription was updated.
https://docs.stripe.com/api/invoices/object#invoice_object-billing_reason
I'm taking a closer look at the Event you shared initially to see how those values relate to the action that generated the Event.
subscription_update was used there because the request that caused the Invoice to be generated was a request to update the Subscription:
https://dashboard.stripe.com/logs/req_ysE0HSWrhLcth0
subscription_cycle is used when the subscription naturally moves from one billing period to the next.
lusty arrow
would a trial end trigger a subscription_update?
nova magnet
No, I'm pretty sure it wouldn't, if the trial period ends naturally rather than forcibly being ended by an update request. I believe that would result in a subscription_cycle billing reason being used. But you can use our Test Clocks to quickly confirm that is what you see in your account:
https://docs.stripe.com/billing/testing/test-clocks
lusty arrow
would it be possible to use testclock in live mode at all?
would you be able to help me identify why this event is a subscription_update?
nova magnet
No, they're a testmode only resource.
nova magnet
`subscription_update` was used there because the request that caused the Invoice...
Because it was updated by the request that I shared previously
The request to update the Subscription forcibly ended the trial period.
lusty arrow
oh i see i see
this log https://dashboard.stripe.com/logs/req_ysE0HSWrhLcth0
shows that we forcibly ended the subscription which gave the event a billing_reason = subscription_update
is that right?
nova magnet
Yup. A request was made to update the Subscription, that update caused an Invoice to be generated for the Subscription, so the billing_reason on that Invoice is subscription_update.
lusty arrow
i see. okay thank you