Question: Is there any way to know ahead of time that a product is suspended?
How to reproduce error: I was trying to update the cost of a variant through the REST API but I received the error “Product is suspended.” in response.
Context: A fetch of that Variant and Product returns a very normal looking product. The product’s status is “draft”. The store is not suspended.
Question: Is there some attribute of a product that I’m not noticing that would indicate that the product is suspended? I would like to avoid getting this error if possible.
Currently, the Admin API doesn’t provide a direct way to identify conclusively is a product is suspended - the closest alternative would be to rely on the status field as you’ve been doing.
A suspended product will appear as draft, however this technique won’t distinguish between a product that is intentionally set to “draft” and one that has been suspended. So you might need to set up some additional context or manual tracking outside of the API to manage this distinction.
I can highlight this as a feature request to the relevant team, but it would be valuable to know your specific use-case, and what the impactful is on having vs not having this feature - this helps product teams to understand the benefits of investment in the feature.
Like I said, the use-case is wanting to set the cost of the variant.
My situation for context: My app has purchase orders. Purchase order has variant cost. When inventory is purchased, my app will try to set the cost of the variant. Stores purchase inventory before selling that inventory. Inventory that is new and not yet for sale will usually be “draft” status. So setting the cost of a new “draft” variant before it goes on sale (“active”) is very normal.
Impact: For my app, the impact is an error response. I try very hard to have zero error responses because usually an error is caused by a bug in the code. So when an error is used to indicate something that isn’t a bug in my code, it is hard to deal with. I end up needing to have complex error handling to account for this specific error that isn’t my own fault. It means that there are now real errors and false errors.
Motivation: If there’s any way to know that it’s disabled ahead of time, then I can avoid getting the error. It means that I can focus on real errors instead of false-errors.
Work-around: I could try to track this on my side, but I think the biggest problem would be knowing when / if the variant later becomes enabled. So I would be reduced to checking whether it is re-enabled again and again and again on repeat. And in many cases it will likely never be enabled I think.
I’ve connected with the products team on this use case - there’s no current plan to support this in upcoming API releases, but this is valuable to help us understand the benefit to investing in support for more verbose responses in these cases.