> ## Documentation Index
> Fetch the complete documentation index at: https://firespark.cloud/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Menus

> Catalogs customers browse on each channel — rooted in your operation, composed per context.

A **menu** is what customers browse — categories, products, prices, photos, and what is available right now. In Fire spark, menus are **rooted in your POS or RMS** and **composed for each selling context**: channel, store, fulfillment type, or schedule.

## Why menus are central

For marketing and commercial teams, the menu is the **main commercial asset** online: what you sell, at what price, with what story. The old problem is not only menu drift between Uber Eats and your app — it is maintaining **separate menu stacks** when strategy actually calls for different offers per surface.

Fire spark starts from one operational source and lets you **shape what each audience sees**:

1. Your team updates items, prices, or 86s something in the POS — the master data stays accurate.
2. Fire spark syncs that foundation and applies the menu rules you configured.
3. Customers see the right catalog for **their** channel, store, fulfillment mode, and time — not a blind copy-paste everywhere, and not a disconnected spreadsheet per partner.

## What you can vary

| Dimension   | Commercial use                                                                  |
| ----------- | ------------------------------------------------------------------------------- |
| Channel     | Full menu on your app; a focused subset on an aggregator; kiosk-only combos     |
| Store       | Regional items, local pricing, or locations that do not list delivery-only SKUs |
| Fulfillment | Delivery menu vs pickup-only items vs dine-in exclusives                        |
| Schedule    | Breakfast vs lunch vs late-night without maintaining parallel integrations      |

You choose when surfaces should match and when they should diverge. Operations still update the POS once; Fire spark decides how that flows into each composed menu.

## Menus are made of

| Piece                                        | Role                                                              |
| -------------------------------------------- | ----------------------------------------------------------------- |
| [Categories](/docs/concepts/categories)           | Group products (mains, drinks, combos)                            |
| [Products](/docs/concepts/products)               | Individual items, modifier groups, bundled items, and modifiers   |
| Modifier groups                              | Choice rules (min/max, display type) and linked modifier products |
| [Recommendations](/docs/concepts/recommendations) | Upsell, cross-sell, and downsell prompts in the ordering flow     |
| Availability                                 | What is orderable now, per store and context                      |

Presentation can differ too — title, image, or placement per channel — without duplicate item masters in your operation.

## Related concepts

<CardGroup cols={2}>
  <Card title="Channels" icon="monitor-smartphone" href="/docs/concepts/channels">
    Surfaces where each menu version appears
  </Card>

  <Card title="Categories" icon="list" href="/docs/concepts/categories">
    Structure inside the menu
  </Card>

  <Card title="Products" icon="drumstick" href="/docs/concepts/products">
    Items customers add to cart
  </Card>

  <Card title="Recommendations" icon="sparkles" href="/docs/concepts/recommendations">
    Upsell, cross-sell, and downsell in the ordering flow
  </Card>

  <Card title="Stores" icon="store" href="/docs/concepts/stores">
    Where availability and local menus apply
  </Card>
</CardGroup>