Let me explain the structure of my store (it’s really simple) first, then I’ll explain why having such an endpoint is a good idea and what problems does it solve.
The store I’m trying to build with Moltin is a simple photo-stock-like site. Each photo in my database has 4 sizes:
xl. So for each product in my DB I’ve created a corresponding Moltin product and build variations with a price modifier. The price of my products depends only on the size parameter.
Now each Molting product has 4 children. I only want child products to be purchasable because I can’t sell the main products (they don’t have sizes) - they are just “dummy” products created just in order to create variations and child products based on them. So I decided to set their statuses to
draft - so that they no longer appear in API responses and are not available for purchase.
In my database, I store Moltin product’s ID-s as properties of my photos. So I have a simple 1:1 relationship between by DB photos and Moltin products.
After I implemented the described data structure I realised that there’s no way I can get child products based on my main products ID-s. The only way to get child products is to get the main product and then get the references of child products. I could do it only if my main products had a status of
live instead of
The only workaround I found (thanks to @Matt from tech support) is to change the statuses of main products back to
live and set their count to
0 in order to prevent them from being purchased … which is kind of a solution, but it seems hacky. I would prefer not to publicly expose products that I’m not able to sell.
I believe that the store I’m trying to build is very generic, so my problem is not an edge-case. An additional endpoint, let’s say:
/products/:id/children/, would solve the problem.