A space to discuss GraphQL queries, mutations, troubleshooting, throttling, and best practices.
is there a way to delete all Shopify products in one Rest API call, please?
At this moment, we would do the following:
GET /admin/api/2021-07/products.json?fields=id
DELETE /admin/api/2021-07/products/632910392.json
Because of Shopify API rate limits (https://shopify.dev/api/usage/rate-limits) we are limited to 2 API calls / second. We have thousands of products on Shopify, which we have to delete and reupload every night to Shopify. Only deleting the products will take over 2 hours. This is quite significant amount of time, considering we will need more time to reupload all the products.
Thank you.
Solved! Go to the solution
This is an accepted solution.
I will share with you my tried and true recipe, to save you and others the pain of thinking about it too deeply.
1. use GraphQL to download your entire Shopify store inventory in one go, Bulk style
2. for that query, ask for the details you'd be wanting to update, or not, up to you. Regardless, you get every ID of every product
Note that since you want to update, and now that you have a Shopify ID, note that you absolutely need to be able to use this information to match your external data. Likely using SKU or barcode for that. Hence my point above. GQL is super for asking for just such info. Note that smart people download the JSONL file, reverse it, and then quickly build up a data structure in memory, that serves as your Shopify dictionary per se.
So now that you have Shopify at your disposal, note that this has not taken too long either. Fantastic.
3. Get your external data in some kind of data structure now too. Since you probably set a key (Shopify product ID) to point to an array of variant IDs (SKU or barcode), you can now quickly look up an entire Shopify product in the external data for data, and prepare for an update. Once you have that data structure set (an entire Shopify product is now ready for an update, you make that one API call).
You will encounter external data that was not touched. Perhaps that is NEW data you need to consider. Deal with it. You may have Shopify variants not found too. Again, deal with that. In the end, you will be keeping your Shopify inventory as fresh as you can, and not running any kind of out-of-control algorithm. This is all nice, neat, and tight. Easy to customize too.
How many products are you talking about?
Why do you need to continually delete and recreate products? That sounds weird but would like to understand the use case.
I have the exact same problem but I have a valid use case for deleteAll. I accept contracts to do weird stuff with Shopify. One weird thing is to take data representing products that are definitely NOT ready for Shopify and bring them to life inside Shopify. To do this requires a lot of data manipulation, and hence API calls. So one can accept say 20,000 products as a bunch of raw data, not in Shopify, and then press a button, and let the API calls try and make 20,000 Shopify products. Boom. Use case!
If the script works, you're golden. But there are exactly zero programmers out there that can pull that off on the first try. So when that script fails, and you have 2, 3 or 4 thousand products but now you need to start over, the first thing to do is erase the products created. And then you run into this. A loop is needed to delete all products. And it takes time! Sometimes, hours! Totally understand why, but it is a real thing for some operators that run into issues. A single typo that screws up images, or vendor, or a variant title. And boom, you need to delete what happened and try again.
So this use case is definitely NOT related to the OP, they are probably doing something weird for sure, but anyway... I for one, would love a call to a mutation labelled deleteAll, that accepted some list of ID's... and then provided me with an answer as to when complete. Who knows, maybe that even exists now... I have not checked in a while.
Hello Jason,
we are talking about 6.000+ products.
The company uses internal goods management system, which serves as their main database of all the goods they have. They want to export their products to Shopify to start selling there.
The company makes daily adjustments, corrections, and modifications to their goods in the database (price changes, corrections of typos and other mistakes, more and better images, etc..). Obviously, they do not want to do do all the corrections twice (once in their internal system and once in Shopify).
I would need to keep track of the previous product state and compare it to the latest product state to discover changes. Then I would have to to individually update products in Shopify. From my point of view, it would be faster to develop and more reliable to delete and reupload all the products every night.
Therefore, I am interested in knowing how to do this operation as fast as possible.
I have a system exactly the same as you ReneK, with 30,000 to 60,000 SKUs. Instead of delete and upload new products, you can take advantage of simple applying the new data, and thus your update operation. So the internal system in use at that company is in a state of flux. Understood. Feed that data on a daily basis to an update routine. Skip the deleteAll/Create.
You'll still have to monitor API limits, but this update script does not really cost you anything to create, since you already wrote the create script. They are very much similar. You want to be careful though not to have a situation where you upload duplicates of things like images, so some logic to ensure you're actually uploading only new content is useful as a work step. I also use the philosophy that the records coming from the internal system are the ones to be made official on Shopify, so if an image resides on Shopify for a product that no longer resides in the internal system (or a variant as another example), I ensure that the update takes care of removing the cruft too.
That is not hard to add to the "update process" as I call it. It is a set-it-and-forget it job I schedule to happen once a day, in the middle of the night.
Hello HunkyBill,
thanks a lot for your responses. Understood. You recommend updating instead of deleting/re-creating. Can I clarify few points to ensure, I am on the right trackt:
You use one of these REST API calls possibly their GraphQL Alternatives:
PUT /admin/api/2021-07/products/632910392.json
This would mean that:
I think, it is very good idea. Could you please confirm, that you are doing all the stuff above?
Thanks many times.
Rene.
This is an accepted solution.
I will share with you my tried and true recipe, to save you and others the pain of thinking about it too deeply.
1. use GraphQL to download your entire Shopify store inventory in one go, Bulk style
2. for that query, ask for the details you'd be wanting to update, or not, up to you. Regardless, you get every ID of every product
Note that since you want to update, and now that you have a Shopify ID, note that you absolutely need to be able to use this information to match your external data. Likely using SKU or barcode for that. Hence my point above. GQL is super for asking for just such info. Note that smart people download the JSONL file, reverse it, and then quickly build up a data structure in memory, that serves as your Shopify dictionary per se.
So now that you have Shopify at your disposal, note that this has not taken too long either. Fantastic.
3. Get your external data in some kind of data structure now too. Since you probably set a key (Shopify product ID) to point to an array of variant IDs (SKU or barcode), you can now quickly look up an entire Shopify product in the external data for data, and prepare for an update. Once you have that data structure set (an entire Shopify product is now ready for an update, you make that one API call).
You will encounter external data that was not touched. Perhaps that is NEW data you need to consider. Deal with it. You may have Shopify variants not found too. Again, deal with that. In the end, you will be keeping your Shopify inventory as fresh as you can, and not running any kind of out-of-control algorithm. This is all nice, neat, and tight. Easy to customize too.
Hello HunkyBill,
nothing more to say or ask, just big "Thank You!" for finding time and describing you approach in such detail. It was pleasure to read it. I am marking your answer as the "Accepted Solution". Take care.