Products

A product is a sellable item on the menu: a burger, a combo, a drink, a side. It carries price, description, modifier groups (choices the customer must or can make), and availability per store.

What commercial teams should know

Topic	In practice
Pricing	List price, tax, quantity limits, anchor pricing, and modifier configuration per context
Bundled items	Products included in combos or bundles, with refund rules when the customer removes an item
Modifier groups	Structured choices (drink, side, size) shape the offer and average ticket
Availability	When an item is 86’d in the POS, it should disappear everywhere customers order
Imagery and copy	Owned channels show your assets; aggregators may have their own layout rules

Products are the level where merchandising meets operations. Marketing promotes specific items; the kitchen must receive exactly what was configured.

Modifier groups and modifiers

Customization on a product is organized in modifier groups. Each group asks the customer a question; each answer inside the group is a modifier.

Concept	What it is	Example
Modifier group	A set of related choices on one product — often with rules (required, pick one, pick many, min/max)	“Choose your drink”, “Add extras”, “Select size”
Modifier	One selectable option inside that group	Coca-Cola, Sprite, bottled water

A group is the frame (“what drink do you want?”). Modifiers are the options the customer picks.

Modifiers can be their own products

In many menus, each modifier is not just a label — it points to a real product in your catalog. The combo does not embed a fake “Coke” string; it offers the same Coca-Cola product you sell standalone, with its own SKU, price delta, and kitchen mapping.

Combo Meal (product)
└── Modifier group: "Choose a drink" (required · pick 1)
    ├── Coca-Cola (modifier → drink product)
    ├── Sprite (modifier → drink product)
    └── Still water (modifier → drink product)

That pattern matters commercially and operationally:

Combos and bundles — Base item + customer picks drink, side, or dessert from real catalog items.
Upsell — “Add bacon” or “Make it large” as optional groups with priced modifiers.
Kitchen accuracy — The ticket names the actual product the line cooks or pours, not an informal note.
Inventory and 86 — If still water is out of stock in the POS, that modifier disappears from the group across channels.

Groups can be required (customer must choose a drink) or optional (add extra cheese). Rules like “pick exactly one” vs “pick up to three toppings” live on the group, not on each modifier. Fire spark syncs products, modifier groups, and modifiers from your operation. The same structure can appear in different composed menus by channel, store, fulfillment, or schedule — without duplicate masters in the POS.

Variants and variant groups

Some POS systems store each configuration of an item as its own product. A pepperoni pizza in medium thin crust has one PLU, and a large thick crust has another. Customers still expect one card (“Pepperoni pizza”) and a couple of questions. Variants model that: the answers don’t add extras, they reveal which product is actually being bought.

Concept	What it is	Example
Variant group	A question asked on the base product, listed in `variant_groups`	”Size”, “Crust”
Variant	One answer in that group, with the products it can lead to	”Large” → `pep-l-thin`, `pep-l-thick`
Base product	The card customers open; it sets `pricing.variant_group_ids`	`pepperoni`
Variant product	The real PLU sent to the kitchen; it sets `pricing.variants`	`pep-l-thick`

Pepperoni pizza (base product · variant_group_ids: size, crust)
├── Size:  Medium | Large
└── Crust: Thin   | Thick
        ↓ Large + Thick
    pep-l-thick (variant product · its own price and modifier groups)

How variants differ from modifiers:

The base is only a selector. It never goes into the cart. The order line is the resolved variant product, with its own price, tax, availability, and modifier groups.
One answer per group. Variant groups have no quantities or min/max rules. Every group on the base must be answered.
Variants come first. Channels ask the variant questions before showing the resolved product’s modifier groups.
Base products can’t have modifiers. A product with variant_group_ids can’t also set modifier_group_ids; put the modifier groups on each variant product instead.
Bases work as modifiers too. A modifier group can list a base product, for example a “Soda” base in a combo’s drink group. The base’s pricing.modifiers entry for that group sets the quantity limits and default. The customer answers the base’s variant questions inside the modifier, and the cart line is the resolved variant product, along with its own modifier groups. That variant’s pricing.modifiers entry for the group sets the charged price and tax; without an entry, its own pricing.price applies.
Only real combinations are offered. As the customer answers, options with no matching product disappear. Options whose product is out of stock stay visible but disabled. Hidden or inactive variant products are treated as missing.
Starting price. When omitted, the base’s starting_price is the starting price of its cheapest selectable variant.

Both sides of the link are explicit so the sync can verify them. Each variant lists its product_ids, and each variant product lists, in pricing.variants, the base product_id plus the variant_group_option_ids that select it. A product can be a variant of more than one base. Variant products don’t need to appear in a category, modifier group, or recommendation. The base being reachable is enough: the sync counts its variant products as referenced, and channel search lists both the base and each variant product. A menu sync is rejected, with an error that names the entity, when any of these rules fails:

Rule
Variant group ids are unique, and variant ids are unique across the whole menu
Every `variant_group_ids` entry exists and isn’t repeated; every variant group is used by some product
A base product has no `modifier_group_ids` and no `pricing.variants` (no nested variants)
Every `product_ids` entry exists and isn’t repeated within a variant
Each `pricing.variants` entry points to an existing base, and only once per base
Variant links can’t be circular: a product can’t resolve from itself, directly or through other products
Its `variant_group_option_ids` pick exactly one option from every group on the base, and nothing else
The chosen options list the product in their `product_ids`, and every option that lists a product is matched by its entry
No two variant products of the same base share the same combination; every base has at least one variant product
Modifier groups can’t loop back to a product, including through a base and its variant products

See the Variants menu sync example for a full payload.

Pricing and bundles

Each product carries a pricing object per channel, store, and fulfillment context:

Field	Meaning
`price`	List price customers see
`is_tax_inclusive` / `tax_rate`	Whether tax is included and at what rate
`minimum_quantity` / `maximum_quantity`	Order limits for this item
`anchor_price` / `anchor_price_percentage`	Reference price and discount for merchandising
`starting_price`	Lowest price a customer can pay once required modifiers are chosen
`modifier_group_ids`	Modifier groups attached to this product
`modifiers`	Per-modifier pricing overrides (default quantity, display type, charge rules)
`variant_group_ids`	Variant groups asked on this base product
`variants`	Base products and options that select this product as a variant

Starting price

Some products can’t be ordered at their list price because a required modifier group adds a charge, for example a pizza where every size costs extra. starting_price is the reference price customers see in that case. Product cards show “From $X” instead of price whenever starting_price is higher than price.

Value you send	Result
Omitted	Fire spark calculates it during menu sync from the cheapest selection that satisfies every required group and modifier minimum
A number	Fire spark uses that number as is
`null`	No starting price; cards always show `price`

The calculation uses the same rules as checkout: per-modifier and per-group minimum_quantity, modifier maximum_quantity, charge_above_quantity, and nested required groups. Each menu sync log records how many products had their starting price calculated. Bundled items model combos: each entry references a real catalog product with an included_quantity and a refund_price if the customer starts a dispute about the bundle.

Menus

Full catalog synced to channels

Orders

Products and modifier choices in a purchase

Get Started

Integrations

Guides

Use cases

What commercial teams should know

Modifier groups and modifiers

Modifiers can be their own products

Variants and variant groups

Variant validation in menu sync

Pricing and bundles

Starting price

Categories

Menus

Orders

​What commercial teams should know

​Modifier groups and modifiers

​Modifiers can be their own products

​Variants and variant groups

​Variant validation in menu sync

​Pricing and bundles

​Starting price

​Related concepts

Categories

Menus

Orders

What commercial teams should know

Modifier groups and modifiers

Modifiers can be their own products

Variants and variant groups

Variant validation in menu sync

Pricing and bundles

Starting price

Related concepts