Menu Synchronization (Fetch Menu)
This section explains the asynchronous process UEAT uses to request a menu synchronization from the POS system. The goal is to ensure UEAT has the latest menu data for accurate ordering.
For a Menu Push see Menu Synchronization (Push Menu).
Flow Overview
As a UEAT Backoffice user, you can trigger a menu sync to refresh data from the POS. The process involves:
- Trigger Sync – BO user initiates the sync request in UEAT.
- Send Sync Request to POS – UEAT sends an asynchronous request to the POS system via the Broker.
- POS Acknowledges Request – The POS responds with an acknowledgment (HTTP status only).
- Menu Payload Returned – The POS later sends the actual menu payload in a separate call.
- UEAT sends an acknowledgement with errors if applicable.
Sequence Diagram
sequenceDiagram
participant Broker as UEAT
participant POS as POS
Broker->>POS: Send sync request
POS-->>Broker: Acknowledge request received
POS->>Broker: Menu payload
Broker->>Broker: Assemble menu response
Broker-->>POS: Acknowledge with errors (if applicable)
Authentication
All requests must include a Bearer token provided by UEAT during onboarding.
See authentication for details.
Sync Request Details
UEAT will issue a POST request to the partner-provided URL. The target URL must be hosted by the POS partner and reachable from UEAT infrastructure.
Endpoint Example
UEAT will issue a POST request to the partner‑provided URL, using the appropriate UEAT ### Endpoint Example
POST {PartnerProvidedUrl}
Authorization: Bearer {JWT_TOKEN}
Content-Type: application/json
Notes:
{PartnerProvidedUrl}is provided by the POS partner.- The
Bearer tokenis environment-specific and must not be shared between Non-Prod and Prod.
Request Payload
{
"requestId": "guid",
"locationId": "guid"
}
Field Definitions
requestId
A unique identifier generated by UEAT for tracking and idempotency.
Partners must echo this value in their response and logs.locationId
The UEAT location identifier assigned by UEAT.
This value must be configured in the partner POS to correctly associate requests with the corresponding merchant location.
Acknowledgment Response
The POS should return only a status code and optional system errors:
Success
200 OK
Failure (system/communication errors only)
Example for invalid location ID:
{
"errors": [
{
"code": "INVALID_LOCATION",
"message": "Location ID not recognized"
}
]
}
Functional errors related to menu content should not be returned here—they will be handled in the subsequent menu payload call.
Menu Payload
The actual menu data will be sent asynchronously after the acknowledgment step.
Payload size should not exceed 9 MB (average is ~200 KB).
Menu Synchronization Example
{
"LocationId": "019a9766-24cc-74c7-bf62-e4277298515f",
"Items": [
{
"Id": "burger_classic",
"Name": "Classic Burger",
"Type": "Item",
"Prices": [
{
"ServiceType": "EatIn",
"Price": 895
},
{
"ServiceType": "Takeout",
"Price": 850
}
]
},
{
"Id": "burger_veggie",
"Name": "Veggie Burger",
"Type": "Item",
"Prices": [
{
"ServiceType": "EatIn",
"Price": 925
},
{
"ServiceType": "Takeout",
"Price": 879
}
]
},
{
"Id": "fries_regular",
"Name": "Fries",
"Type": "Item",
"Prices": [
{
"ServiceType": "EatIn",
"Price": 375
},
{
"ServiceType": "Takeout",
"Price": 350
}
]
},
{
"Id": "drink_soda",
"Name": "Soda",
"Type": "Item",
"Prices": [
{
"ServiceType": "EatIn",
"Price": 295
},
{
"ServiceType": "Takeout",
"Price": 275
}
]
},
{
"Id": "mod_lettuce",
"Name": "Lettuce",
"Type": "modifier",
"Prices": [
{
"ServiceType": "Takeout",
"Price": 0
}
]
},
{
"Id": "mod_tomato",
"Name": "Tomato",
"Type": "modifier",
"Prices": [
{
"ServiceType": "Takeout",
"Price": 0
}
]
},
{
"Id": "mod_onion",
"Name": "Onion",
"Type": "modifier",
"Prices": [
{
"ServiceType": "Takeout",
"Price": 0
}
]
},
{
"Id": "mod_cheese",
"Name": "Cheddar Cheese",
"Type": "modifier",
"Prices": [
{
"ServiceType": "Takeout",
"Price": 125
}
]
},
{
"Id": "mod_bacon",
"Name": "Smoked Bacon",
"Type": "modifier",
"Prices": [
{
"ServiceType": "Takeout",
"Price": 175
}
]
}
],
"Categories": [
{
"Id": "cat_burgers",
"Name": "Burgers",
"Items": [
{
"Id": "burger_classic",
"ModifierGroups": [
"mg_burger_toppings"
]
},
{
"Id": "burger_veggie",
"ModifierGroups": [
"mg_burger_toppings"
]
}
]
},
{
"Id": "cat_sides",
"Name": "Sides",
"Items": [
{
"Id": "fries_regular",
"ModifierGroups": []
}
]
},
{
"Id": "cat_drinks",
"Name": "Drinks",
"Items": [
{
"Id": "drink_soda",
"ModifierGroups": []
}
]
}
],
"Modifiers": [
{
"Id": "mg_burger_toppings",
"Name": "Burger Toppings",
"Modifiers": [
"mod_lettuce",
"mod_tomato",
"mod_onion",
"mod_cheese",
"mod_bacon"
]
}
]
}
| File | Description |
|---|---|
| Example Synch Payload #1 | Synch Menu example |
Supported Item Types
- Standard items
- Modifiers
Combos are not supported at this time.
Workaround for Combos
- Represent the combo as a regular item.
- Add individual components as modifiers.
- Ensure pricing logic avoids double-charging.
Simple Menu Payload Example
This example shows a flat list of items without modifier groups in case a more structured Menu isn't supported by the POS (this should be discussed and approved during the qualification phase).
Even for a Simple Menu Payload, you must provide a categorie as a placeholder :
{
"Items": [
{
"Id": "coffee_001",
"Name": "Black Coffee",
"Type": "Item",
"Prices": [
{
"Service": "Pickup",
"Price": 250
}
]
},
{
"Id": "sandwich_001",
"Name": "Ham Sandwich",
"Type": "Item",
"Prices": [
{
"Service": "Pickup",
"Price": 599
}
]
}
]
}
Best Practices
- Always include
requestIdfor traceability. - Validate
Bearer tokenbefore processing. - Log both the request and acknowledgment response.
- Monitor for timeouts and retry if necessary.