UBER-EATS-Wrapper/docs/developer-portal/05-menus.md

05 Menus

Menu sync between POS and Uber Eats:

• Full menu replacement via PUT
• Fetch menu from Uber
• Item-level updates (out-of-stock/price updates)
• Item and modifier mapping strategy
• Validation and publish error handling

Current wrapper route for full replacement:

• PUT /api/v1/uber/menu/replace
• upstream mapped to PUT /v2/eats/stores/{store_id}/menus
• request body is gzip-compressed for upload (Content-Encoding: gzip, Content-Type: application/json)
• optional menu.menu_type supported:
  • MENU_TYPE_FULFILLMENT_DELIVERY (default)
  • MENU_TYPE_FULFILLMENT_PICK_UP
  • MENU_TYPE_FULFILLMENT_DINE_IN

Item update route:

• POST /api/v1/uber/menu/items
• upstream mapped to POST /v2/eats/stores/{store_id}/menus/items/{item_id}
• sparse update only (only provided fields are changed)
• wrapper payload shape:
  • merchantId
  • storeId
  • itemId
  • update object with fields such as price_info, suspension_info, menu_type, product_info, classifications, beverage_info, physical_properties_info, medication_info, nutritional_info, selling_info
• reference catalogs for product_info:
  • GET /api/v1/uber/catalog/product-types
  • includes product_types and mixin_types

Menu fetch route:

• GET /api/v1/uber/menu
• upstream mapped to GET /v2/eats/stores/{store_id}/menus
• supports query menu_type:
  • MENU_TYPE_FULFILLMENT_DELIVERY (default)
  • MENU_TYPE_FULFILLMENT_PICK_UP
  • MENU_TYPE_FULFILLMENT_DINE_IN
• sends Accept-Encoding: gzip upstream for large menu payloads

Best-practice note:

• Use API-managed menus only for integrated stores (avoid manual Menu Maker edits to prevent drift).
• Alcoholic item flag is effectively sticky in Uber (alcoholic_items > 0 cannot be reverted by API update).
• Upload route performs preflight troubleshooting checks:
  • no menus, no hours, short-hours (<60 min), overlapping item visibility intervals

Example payload pack:

• See 05-menu-example-payloads.md
• JSON payloads are in docs/examples/menus/v2/