#tom - archive price
1 messages · Page 1 of 1 (latest)
Sorry, meant to include above - is that intended or are we calling the API incorrectly?
And hello!
This is the expected behavior. Once you've marked a Price ID as inactive any API request that includes the archived Price ID will fail
Do you have the ID for a request that you expected to succeed?
Let me see if I can grab one from earlier when was reproducing it
Will PM it to you right now
You can share the request ID publicly. Only Stripe staff or someone with access to your account will be able to do anything with it
si_LUOoIPnxKTEOvb
Okay, that's a Subscription Item but I can find the API request from there
Ah, sorry - did you need the indempotency key?
Nope it's okay
Alright so the Price price_1JQJfMJiSwS8MjMJTXAckzP6 was set to Inactive on 6/6/2022
Right - and I guess the expectation was that users could still update/renew existing subs, but appears that is not the case
And wanted to make sure before needing to handle the price change differently on our front end
Do you have the request ID for the follow up change to that subscription?
Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
Here's an example of one: req_yKGQWhUHAjA54V
Where tried to update units from 15 to 14
Was able to do it via the Stripe dashboard btw, just not via the API
So yeah, the way the active flag works, you can't use that price in any API call once a Price is set to Inactive.
Ahhh, gotcha - so if we wanted to do what I described, we would need to keep the prices active if we wanted to call them for any renewals/edits to existing subs?
Or something to that effect (such as creating a new price id, then sending requests for existing subs to that)
Yes I believe so. You could flag the Price ID as inactive in your system to prevent creating new subscriptions with it and only set it as inactive in Stripe once all your existing Subscriptions no longer use that price.
Yeah, I guess the confusing part with it is how modifications/renewals to existing subscriptions are more or less being treated as new subscriptions
Which does make sense, was just unexpected
Yeah I can understand that. I think it's how we needed to implement strict permissions around the inactive flag to be certain it really would inactivate existing Price records.
If we add too many "well in X scenario what we really want is...." then the rules get too complex to maintain with any certainty
Oh, of course - definitely understand that and can't realistically support every use case! Thank you very much for the help though and really appreciate the clarification!
Sure thing! I'm happy to share more info and potential approaches to achieve your goal