Stock by variation options



Hi !
Is it possible to handle product stock by variation options using the V2 ?
For instance, I would like to dissociate the stock for the size variation of my product: 100 items for L size and 50 items for S size.


Hi Neiluj,

Inventory and stock management are close to release, while that is tangential to your request its just a point of information.

With regard to stock of ‘child’ products, or products generated from variations, these are managed on that child product.
So you should be able able to do an update to the child product, setting its stock level.

Hope this helps.


Hi @ian !

Are talking about the forge implementation ?
Thanks for your answer it should help.

Are the “child” products something that is already handled by the V2 ? Because I don’t find any references to that feature in the V2 api documentation.


Are talking about the forge implementation?
Inventory and stock management? No - this is the internal tooling.

A ‘child product’ is just a concept that indicates there is some base entity that produced the product initially. I think variant product is another commonly used term in the vocabulary…

When you say ‘handled’ - can you embellish a little? I’m not sure what you mean :stuck_out_tongue_winking_eye:


Sorry for my english :blush:

I mean are these variant products automatically managed ?
If I create a product and then link some variations to it, am I able to directly retrieve these variant products using the V2 API ?
I am not talking about retrieving the variation options of a product but the variant products themselves as a final product.

Is it better ? :sweat_smile:


The ‘child’ products (which would be built from the attached variations) would be returned from a GET /v2/products request.

To summarise the product variations workflow:

  • Create a variation
  • Create options for that variation
  • Attach any modifiers (e.g. SKU, slug, name, price) to those options
  • Build the child products (POST /v2/products/{id}/build)
  • GET /v2/products would then return the ‘base’ product as well as the children built in the previous step

There’s an example of a variations workflow on our API reference here. We’re currently in the process of adding product variation functionality to the dashboard :slight_smile:

Hope this helps!


Thank you @jonathan !
Now I get it !

Last question :wink: : I have already tried out the variations feature on the V2 API and I created some options and modifiers. The missing feature for now is the “child” products build from the base product. Will this feature be retroactive or will I need to redo my variations, options and modifiers to make appear these “child” product ?


Whenever you make a change to a variation, option or modifier you’ll need to ‘build’ the child products again for the changes to take effect.

POST /v2/products/{baseProductId}/build


Ok I did not realize that this request was already available !
Thanks a lot @jonathan !


No problem! :upside_down_face: :rocket:


As I am testing the modifiers requests I noticed I can not create a slug_builder modifier. The API always return this message: "The selected data.modifier type is invalid."

Here is the body I send in my request:

  "data": {
    "type": "product-modifier",
    "modifier_type": "slug_builder",
    "value": {
      "seek": "DESIGN",
      "set": "marbre"


slug_builder is not a valid modifier_type. Did you mean to use sku_modifier? See here for an explanation.


That’s strange because the documentation is not saying the same :

By the way the type “sku-builder” is wrong as the right value is “sku_builder”.


Oops, I think that has been documented a little prematurely. It isn’t available just yet unfortunately.


Alright !
I will do without it for now.
Thank you for your availability @jonathan !


Any ETA on this? I’ve read is planed for v2 too


Hi @agusti

Right now I don’t have a date for when the API/SDK and Dashboard will support this but if nobody else beats me to it first, I’ll tag you here as soon as this arrives :grinning:



OK @notrab, so in the meanwhile, and to not use this an excuse to discard moltin for now.

Can I use the API to create those variations? Is only the client/dashboard implementation what’s missing?

Any public roadmap? A github trello-style would be awesome.

Really want to use moltin but not 100% sure if it covers all my use-cases.


Hey @agusti

There is no stopping you from using the API directly to do what you need around variations. It is only the Dashboard that doesn’t support this functionality but we are working hard to bring continuous updates to the Dashboard and when they arrive, we’ll announce them :slight_smile:

A public roadmap is a great idea and something I’ll share with the team.

I’m more than happy to connect you with my colleague Owen or @Matt who would be more than happy to have a call and discuss your requirements and use cases.

DM me if this is useful and I’ll get you connected :smiley:


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.