Manage products and variants

Every product in the catalog lives under /products. If it is sold in sizes, colors or capacities, it has variants: one row per combination, with its own SKU, price, inventory count and options. Reading needs marketplace:read; writing, marketplace:write.

Variant attributesCopy Anchor Link

Whatever differs between variants and is not a purchase option goes in attributes: a flat map of strings, numbers or booleans. For example, the battery range of the units behind a SKU.

curl -X PATCH "https://api.vitrinadev.com/api/v1/products/$PRODUCT_ID/variants/$VARIANT_ID" \
  -H "Authorization: Bearer $VITRINA_KEY" \
  -H "Content-Type: application/json" \
  -d '{"attributes": {"battery_min_pct": 99, "battery_max_pct": 100}}'

The response carries the whole variant, with "attributes": {"battery_min_pct": 99, "battery_max_pct": 100}. A variant with no data returns {}.

• POST /products/{id}/variants and PATCH /products/{id}/variants/{variantId} accept attributes; so does each element of variants[] when creating a product.
• Each key uses letters, digits, _, . or - (up to 60 characters). Each value is a string (up to 300), a number or a boolean. Objects, lists and null are refused.
• Up to 20 keys and 2 KB per variant. Beyond that the response is 400 VALIDATION_ERROR.
• PATCH replaces the whole map: send every key you want to keep. {} clears it.
• The sales agent reads attributes from search_product_stock to answer questions such as «what battery does it have?».