Products and variants
Products and variants
A product describes what you sell. A variant identifies the specific option a buyer purchases and operations fulfill. Even a product with no selectable options needs a variant for cart line items.
Put data at the right level
| Product | Variant |
|---|---|
| Shared name and description | Option name and selected attribute values |
| Vendor, tags, categories, and collections | SKU, barcode, and weight |
| Product-wide custom fields | Variant-specific custom fields and media |
| Product status and publications | Variant status, publications, prices, and inventory relationship |
For a Copenhagen Lamp offered in black and white, create one product with two variants. Each finish has its own SKU and may have a different image, price, or stock quantity. Changing the selected finish should update the entire variant presentation, not just its label.
Model options with attributes
Attributes describe reusable choices such as color or size. Assign the relevant attributes to the product, then select their values on each variant. Do not manufacture a SKU from an option label in the storefront. Use the variant ID returned by Thor when adding an item to a cart.
Existing is different from sellable
Product and variant status are separate from publication. Both levels must be configured for the intended distribution channel. A variant also needs a usable price and the availability required by its inventory policy. Read Catalog visibility for the complete diagnostic sequence.
Keep identities stable
Use Thor IDs for relationships and a stable SKU for stock synchronization. Renaming a product should not create a new product record. Treat a SKU change as a change to your inventory mapping and coordinate it with the system that owns stock.
Follow Create and publish a product for the API operations in dependency order.