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: