Conversations about creating, managing, and using metafields to store and retrieve custom data for apps and themes.
Getting this error very rarely. Happens on updating metafields and description alone (separate calls). Looks like a real bug and needs to be fixed...
422 / Unprocessable Entity / {"sku":["can't be blank"]} /PUT /admin/products/4454726828086.json
x-request-ids:
7cc1ad1e-2398-40d0-9532-27c7718a5558
af09ee9c-8100-4477-8e3d-f4068497fc1e
413d46bb-0d5e-452e-8ca1-c6bf192e558e
Hi @Jason27 ,
Thanks for providing the X-Request-ID, that was helpful.
The reason why these errors are being thrown is because this specific Product (ID: 4454726828086) has invalid Product Variants associated to it due to their blank skus. Due to these invalid Product Variants with blank SKUs, you cannot make any updates tp this specific Product with PUT requests until these Variants and their issues are resolved.
There are approximately 20 of these invalid Product Variants associated to the Product ID 4454726828086, and they just need to be updated so the SKU goes from "" (e.g. blank) to an actual string value.
To learn more visit the Shopify Help Center or the Community Blog.
Hi Hassan, thanks for getting back to me. I think the logical next questions are:
Why and how are these SKU's missing on this specific merchants product(s)?
I don't see this error with thousands of other merchants.
Do I need to check for blank SKU's on each product variant from now on because if there are blank SKU's the update (PUT) will fail - even when the update array does not include variants !?
Why is this allowed to happen in the API?
This seems like a bug to me, not something I should have to think about, especially since there is no way for me to figure out what a blank SKU value is meant to be, so I can't fill it in either. I think you should pass it up the chain.
Hi @Jason27 ,
Why and how are these SKU's missing on this specific merchants product(s)?
If you are not the shop owner yourself, you will have to reach out to merchant and ask them why they created invalid Product Variants for their store without any SKU numbers.
I don't see this error with thousands of other merchants.
Probably because most merchants do not create invalid Product Variants that do not have SKU numbers
Do I need to check for blank SKU's on each product variant from now on because if there are blank SKU's the update (PUT) will fail - even when the update array does not include variants !?
No. If you get the error message " {"sku":["can't be blank"]} " when you are trying to update a product you will know that this error happened because there was a blank SKU present. You should be able to easily catch/throw this error in your app, and then reach out to the merchant to have this issue resolved.
Why is this allowed to happen in the API?
Most likely this did not happen in the API - the merchant most likely created these invalid Product Variants in their store's Web Admin and while creating them they set/left the SKU blank
To learn more visit the Shopify Help Center or the Community Blog.
If you are not the shop owner yourself, you will have to reach out to merchant and ask them why they created invalid Product Variants for their store without any SKU numbers.
Since when are merchants required to create SKUs for a product or product variant? Many do not. Check your database, there must be millions of records with no SKU.
If a merchant does not use SKUs it is a bit ridiculous to tell them to change their business process to use SKUs just because of the API design.
Hello. We are facing the same issue as well when we try to set SKU for variants using API. As this is not a mandatory field in Shopify, some of our customers do not add this, so it's a valid scenario. Having these SKUs is required for us so that we can set us as a fulfillment service for this product. Are there any plans on fixing this? So that we would not have to reach out to our customers asking them to manually fix these variants. Thanks in advance!
I found it is only happens on REST API, if you use GraphQL API then it is fine. 😞