veequeetch_api

[ancient vessel]

👋 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/1319466284252921867

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[steep schooner]

Am I misunderstanding what subscription.canceled_at represents?

[bitter wedge]

Hi 👋

The subscription.canceled_at property represents the timestamp of when the API request was made that included parameters related to canceling the subscription

That's worded a little vaguely because there are a few parameters you can use

So, if I have a Subscription that is billing me from 12/1 /2024- 1/1/2025, and I make an Update request and pass cancel_at_period_end: "true" https://docs.stripe.com/api/subscriptions/update#update_subscription-cancel_at_period_end, the Subscription will cancel on 1/1 but the canceled_at property will have the timestamp of the request

[steep schooner]

I see

What happens on a follow up cancel request where the sub cancels "now"?

Does the timestamp get updated again?

[bitter wedge]

Yes it should

But we can test that out

[steep schooner]

The req_zDPVmC8W5fwvph represents our system initiating a cancellation on the subscription (today), but the cancelled_at maintained the prior request timestamp dated back on August 30.

The canceled_at value is 1725010095 in the response body

Based on the request timestamp the expectation of the value should be around 1734607517, based on what you are sharing on how it should behave.

While we reconcile this, how reliable is subscription.ended_at? If the subscription was canceled and completed in the middle of the billing cycle does the event timestamp for this field equal to the timestamp when the final cancellation is executed?

[bitter wedge]

This request is not an update request providing a cancelation parameter, it's a delete request. I don't think those behave the same.

[steep schooner]

I see so the canceled_at timestamp is for update events and not necessarily means when a subscription is actually canceled?

That is a bit confusing.

If this is the case, what is a reliable field to read for when the subscription is actually completely canceled? Would it be the subscription.ended_at field?

[spare imp]

👋 catching up and will be here shortly!

Looking at https://dashboard.stripe.com/logs/req_zDPVmC8W5fwvph the cancelled_at is 1725010095, which is the timing of another request: https://dashboard.stripe.com/logs/req_bUyPQI1DqMkkgK

This one from a Billing Portal, when the Customer cancelled it, and as my colleague mentioned, it's the timestamps of the request itself

[steep schooner]

I have no insight to req_bUyPQI1DqMkkgK as its not showing up on my work bench

But I am following what you are saying, where req_bUyPQI1DqMkkgK set the timestamp to canceled_at, which is also the same timestamp in the response of req_zDPVmC8W5fwvph

Request req_zDPVmC8W5fwvph is a request to end the subscription (via DELETE). It is now my understanding the canceled_at does not get updated from this type of request?

If I just want to know the timestamp of when the subscription does get canceled, like completely ended, is subscription.ended_at the more appropriate field to read?

Just to be clearer the req_zDPVmC8W5fwvph request was from interacting the cancel endpoint: https://docs.stripe.com/api/subscriptions/cancel

[spare imp]

Yes I can see that's the DELETE request, should be from the cancel endpoint 👍

Request req_zDPVmC8W5fwvph is a request to end the subscription (via DELETE). It is now my understanding the canceled_at does not get updated from this type of request?
Yes. I agree it's a bit confusing here. This value is still derived from req_bUyPQI1DqMkkgK
If I just want to know the timestamp of when the subscription does get canceled, like completely ended, is subscription.ended_at the more appropriate field to read?
https://dashboard.stripe.com/events/evt_0QXpLVWciwNzvqwFQ0D1Ppv0 see

ended_at: 1734636317,

[steep schooner]

It does look like the ended_at field is what I would want to use. I just want to make sure there isn't some gotcha understanding to it like canceled_at

[spare imp]

Hmm why you don't want to use ended_at? It's the exact timing the Sub is ended, and also the timing of customer.subscription.deleted webhook

[steep schooner]

I don't have anything against using it. I plan on using it now. Where I am coming from is I want to make sure I understand the field because obviously I missed the mark on canceled_at. It wasn't super clear how that field behave, which honestly is having me not be super confident on how the other fields may behave. But if you say the field does exactly what it says it does then thats good enough for me.

[spare imp]

Yes it should be good enough. I agree canceled_at was confusing. But this ended_at should be it

[steep schooner]

Sounds good. I appreciate the assistance.