Special Use Cases

This section outlines how UEAT handles special order types such as Hub Orders, Kiosk Orders and other use cases. These use cases are identified through specific fields in the order model and may require unique handling by the POS.

Hub Orders

Hub orders are routed through a centralized delivery or marketplace system. They are identified by the Service.Channel field in the order payload.

Identification

"Service": {
  "Channel": "skip-the-dishes" | "uber-eats" | "doordash" // Indicates a hub or marketplace order.
}

The channel name determines how certain fields are populated and processed in the order payload.

Key Considerations

These orders originate from third-party platforms.
Delivery details are often managed outside the restaurant.
The Tip for delivery is managed outside the restaurant.
Payment type includes a specific PaymentType enum for hub transactions.
It's possible that UEAT will add new values to this enum in the future.

Kiosk Orders

Kiosk orders are placed directly by customers using in-store kiosks. They are identified by the presence of a Service.Channel indicating kiosk.

Identification

"Service": {
  "Channel": "KIOSK",
  "KioskId": "string" // Identifier of the kiosk device
}

Key Considerations

KioskId is an alphanumeric identifier, not a label such as “Lobby”.
Customer information may be partially or fully missing (e.g., no email or name).
Orders are always for ASAP preparation.
- See PreparationType for details
POS should distinguish kiosk orders for routing and reporting.
Tip handling and simplified menu navigation may differ.
Kiosk orders should not include delivery info.
A kiosk order may be for take‑out or dine‑in.
- See OrderType for details

Ghost Kitchen

The Ghost Kitchen model can be applied to different business models.

The first concept is having two different brands using the same location and the same POS to receive orders. In UEAT, these two brands will have a separate BackOffice but it is essential that the POS can accept two separate POS configurations to receive orders.
The second concept is mostly applied to a restaurant offering catering services. This location is using the same UEAT BackOffice but will have two different offers on the online ordering and usually two different menus. This concept will also require two different POS configurations.

Identification

The way to differentiate from which POS configuration the order is coming from is the Location ID.

Key Considerations

Important : Considering the orders are coming from two different online orders, it is very possible that the OrderId is the same for the two different locations on the same day. Your POS must be able to accept this use case or distinguish the LocationId to fully support ghost kitchen and catering business models.

Summary

Use Case	Identifier Fields	Notes	Restrictions
Hub Order	`ExternalOrderId`, `ExternalDeliveryId`	External delivery, marketplace integration	`DeliveryInfo` : will be null if the order is a Hub delivery order `PaymentType` : is always Hub
Kiosk Order	`Service.Channel = KIOSK`	May lack customer info, ASAP prep, in-store flow	`Customer` : All fields can be empty here depending on what is configured on the kiosk.
Ghost Kitchen	`LocationId`	`OrderId` is the same for the 2 different locations on the same day

These identifiers should be used by POS systems to apply appropriate logic for processing, routing, and reporting.

Table of Contents