Variants

A variant is one purchasable SKU under a product, such as the 500 mg orange version of a vitamin. Variants are distinguished by variant axis attributes (size, colour, strength), can override other attribute values, and carry their own identifiers and media. Options that change an order line without creating a SKU, like engraving, are modifiers instead.

In the admin

Variants are created from axis values, so first mark at least one attribute on the product’s family as a Variant axis (see Attributes).

1. Open a product under Catalog → Products and scroll to Variants.
2. Click Generate matrix.
3. Under Axes, enter values for each axis, one per line or comma-separated. For a select axis, click the listed options to add them.
4. Adjust the SKU template if needed. Placeholders are {axis_code}.
5. Pick Status for generated variants, check the Preview for collisions, then click Generate N variants.

Click Open → on a variant row to see its Identity (SKU, status, position), Axes, Overrides, Identifiers and Media. You can edit the SKU and status there, or change status and delete straight from the product’s variant table.

With the API

Method	Path	What it does
GET	/v1/products/{id}/variants	List a product’s variants, ordered by position
POST	/v1/products/{id}/variants	Create one variant
POST	/v1/products/{id}/variants/matrix	Generate every combination of axis values
GET	/v1/variants/{id}	Fetch one variant (includes productId)
PATCH	/v1/variants/{id}	Partial update
DELETE	/v1/variants/{id}	Delete

curl -X POST https://api.minipim.com/v1/products/0b8c5d3a-…/variants/matrix \
  -H "Authorization: Bearer pim_…" \
  -H "Content-Type: application/json" \
  -d '{
    "axes": { "strength_mg": [500, 1000], "flavor": ["orange", "lemon"] },
    "skuTemplate": "VITC-{strength_mg}-{flavor}"
  }'

This creates four variants, VITC-500-orange through VITC-1000-lemon, and returns them as created. Full reference: api.minipim.com/docs.

Rules and limits

• sku is required and must be unique across the whole organization, not just the product.
• Variant attributes are validated against the parent product’s family. Codes the family doesn’t declare are rejected.
• Variants skip the required-attribute check entirely, and a variant’s status (default draft) has no publish gate.
• Every matrix axis must be an attribute on the family flagged as a variant axis; otherwise 422. Axis values are validated per combination, so a select axis with a closed list only accepts its options.
• Matrix values are written unscoped (locale: null, channel: null).
• Without skuTemplate, matrix SKUs are the product slug plus each slugified value, joined by -. A template placeholder that isn’t one of the supplied axes is a 422.
• If any generated SKU already exists, the whole matrix fails with 409 and nothing is created.
• PATCH merges attributes per code, like products: values replace that code, [] clears it, omitted codes are kept.
• The API returns only the values stored on the variant. Falling back to the product’s value for anything the variant leaves blank is up to the client; the admin shows those as inherited.
• Variant-axis attributes are hidden from the product’s own attribute editor, since their values live on the variants.
• Deleting a variant deletes its identifiers. Deleting the product deletes all its variants.
• Writes emit variant.created, variant.updated and variant.deleted.