# 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](/concepts/catalog/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](/concepts/catalog/publication) 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](/guides/catalog/create-product) for the API operations in dependency order.