How to delete a price using API

[moskrc]

Hello,

I want to delete a price inside a product, I can do it in the Stripe dashboard, but I can’t do this using API

Code:

stripe.Price.delete("price_HLez6Zi58HejNP")

Result:

  File "../src/payments/models.py", line 81, in delete
    stripe.Price.delete(self.stripe_id)
AttributeError: type object 'Price' has no attribute 'delete'

Thanks

[remi-stripe]

@moskrc The Price API does not support deletion today. You should instead set active to false on the Price if you don't want to use it again. The only case where a Price can be deleted is when it's mirroring a Plan and this plan is deleted via the API, which we only support for legacy integrations but actively discourage using.

[kirk-marple]

@remi-stripe On this topic, if you don't delete a price, which has been added to a product, you get an error deleting the product.

This product cannot be deleted because it has one or more user-created prices.

Should we just be setting products to inactive too, rather than deleting them?

[remi-stripe]

Yes we recommend keeping your object so that it can help with future reconciliations.

[sasokovacic]

@remi-stripe It doesn't make any sense to be able to delete an unused product and not be able to delete an unused price. It's also not logical that we can delete a price in the Stripe panel but not through the API. You should enable this at least in the development mode where we are adding a lot of dummy data and want to clear some of it after testing. The only option here is to delete all test data from the Stripe panel.

[remi-stripe]

@sasokovacic I agree but in the future we want to remove the ability to delete object and instead default to marking them as inactive and make them hidden. The Prices API is a newer API and replaces the Plans API. Plans could be deleted though so we had to support deletion in the Dashboard for backwards compatibility. If we had removed it, we'd have broken thousands of integrations that expect this flow to works in the Dashboard. Overall though, we are moving away from it and will, in the (far) future, disable this feature. For newer integrations, deleting a Price is something we don't want to directly support which is why you can't do it in the API

[jleclanche]

@remi-stripe I know this is OT for stripe-python but IMO Stripe should consider allowing deletion of prices that haven't been used anywhere. Especially for users doing most of their business directly from the dashboard (eg. using Stripe purely as an invoicing platform), mistakenly creating prices can happen and if no related invoice has been issued, it ought to be fine to delete.

[remi-stripe]

@jleclanche It's really confusing when an API fails in almost all cases though. Being able to delete a Price never used but not delete another Price is a pit of failure for a developer to discover. And FWIW We do allow this in the Dashboard already for that reason.
Overall there's no reason to delete a Price as long as the Dashboard is hiding them by default so it's more that we need to improve the Dashboard overall and not clutter the API with an API method that can almost never be used I think

[sasokovacic]

@remi-stripe what is the reasoning behind this decision? What is so problematic about deleting unused records? It's the most basic functionality in any application. When I build apps for businesses, I always implement soft deletion, but they are also able to hard delete data that doesn't have any value in the system. This is how you enable users to clean up the database frequently and consistently.

[remi-stripe]

@sasokovacic It's related to what I mentioned. You would think you can delete all prices but later discover you can only delete unused prices for example. And if you support price deletion, then in the API you get a truncated version of the object that only returns the id, object and deleted property when what most integrations want is to make the price inactive so that no one new can use it, while keeping the historical record.
I do understand your position and I don't disagree but I wouldn't call it "the most basic functionality" either. At some scale, there is value in data that can be mutated or disappear too.

[QuintinWillison]

I've just stumbled across this issue as I'm working on the "product and price" creation bit of a Stripe integration for someone right now (JS SDK in Node.js but applies just the same, and this issue came up top in Google search). It really makes no sense to me why the "..." menu against a price in the dashboard (the web UI) allows users to "Delete price" but I cannot do the same from the API.

Also, loosely related, I was surprised I could create products and specify the product id myself (good!) but found that I am not allowed to specify the price id myself when creating a price.

Something definitely doesn't sit right here. I was expecting consistency and parity from Stripe across all levels of the UX/DX, given how focussed you are on API / developer first (or at least as far as I understood you were). It just feels a bit curiously incongruous. 🤷

Developers just learning your platform will be thrashing about, in both test and production environments, so I think it's only natural to be able to fix our mistakes by deleting unused and misconfigured objects while we experiment... especially when those experiments are programs / scripts that we're writing to "initialise" our Stripe environments.

[sasokovacic]

@remi-stripe from my experience deletion/soft-deletion is the most basic and most common functionality these days. Also, there is a difference between archived, soft-deleted, and hard-deleted status. IMO Stripe should have at least the first two available through its API. As for truncated objects, you don't have to return them. There is no need for this. You only return active objects by default. Archived and soft-deleted objects can be retrieved explicitly using some parameter or different URI. In the end, it's your decision. I'm just sharing my experiences building many business apps. Some businesses require hard deletion, but most of them require soft-deletion which means these records are not visible anywhere in the app except in some special view for troubleshooting purposes.

[pm-bc]

I will second the comments from Quintin and sasokovacic. I just ran into this myself when attempting to use the API to completely automate some testing our accounting team is doing --- in the test area! Lo and behold I can't use the API to clean up a bunch of test prices, and, well, that really stinks. I see zero reason why deleting prices via the API should be blocked from the test environment.

Second, I even feel that in the production area, it should be allowed as well via API. First, it's the end user's data, and if they make a mistake and want it GONE, that should be their choice. Since people (and especially accountants -- haha!) make mistakes a lot, and since there are numbers involved and the potential for fat-fingering, a good UX for an API-centric product like Stripe is supposed to be would allow this --- or at least give the user the ability to enable such a 'feature' themselves. It's fine if Stripe wants to think that they need to hold everyone's hand on everything, but you don't. If you want to have a default mode where it is disabled, fine, but give us the ability to enable it and use it if we know what we're doing. And we do.

Just food for thought. Thanks for reading.

[remi-stripe]

I see zero reason why deleting prices via the API should be blocked from the test environment.

One reason is that if we didn't block it, you'd build your entire integration thinking it will just work in Live mode only to discover you're down the day you deploy to production. Consistency between Test mode and Live mode is quite crucial for patterns like this and we do our best to approach it this way when we can

As for the second part of your comment, I don't disagree conceptually but we used to support deletion on the Plan API and I have helped countless developers over the years try to recover from deleting the wrong Plan, re-creating a new Plan with the same id and then being thoroughly confused why 2 subscriptions on the "same plan id" had a different amount charged, etc. There is a lot more to it than just deleting to suppress a mistake and over the years as business grows there is a higher cost than you would expect to supporting real deletion in the API.
It doesn't mean we won't bring it back, we're constantly monitoring feedback like this and taking it into account as we evolve our products and APIs and we hear you. I have also shared this thread multiple times internally as we looked into future improvements and changes so it's top of mind for the eng teams maintaining those APIs overall!