Why your Uber Eats menu prices differ from the ones you set

Restaurant operators on Uber Eats are usually reading one of several prices the platform keeps per item rather than a single one. Uber’s Menu API holds price, core_price, in_store_price and in_store_discounted_price on the same object, and every one of them is an integer, because “Price should always be integer value (never decimals) because the price is set in the percent of local currency denomination”. Menu edits are otherwise fast, since Uber states that “all edits except for photo uploads will be live in the Uber Eats app immediately”.

Where is an Uber Eats price stored, and how many prices are there?

Uber Eats separates the portal from the tool inside it. Operators “Sign in to merchants.ubereats.com/manager” and then, “On the left sidebar, click ‘Menu’ to open Menu Maker” (help.uber.com). So Uber Eats Manager is the portal and Menu Maker is the menu editor, and support articles refer to both by name.

Underneath, a single item carries more than one number. Alongside the selling price, the API defines core_price as “The intrinsic value of the item, in the percent of local currency denomination, e.g. cents”, and two separate reference prices, in_store_price and in_store_discounted_price (developer.uber.com). An integration that populates only one of these leaves the others carrying whatever they held before, and the mismatch a team is investigating is often between two Uber fields rather than between Uber and the restaurant.

Why does Uber Eats want to know your in-store price?

Because it uses the difference. The Menu API documents in_store_price as the “Item price merchant charges for in-store purchases, excluding any additional merchant discounts”, and in_store_discounted_price as the “Item price merchant charges for in-store purchases, including any additional merchant discounts” (developer.uber.com). Few platforms ask for the restaurant’s own shop price as a structured field at all, and none of the Gulf platforms do.

That field feeds a published metric. Uber explains that “Your menu markup metric measures how closely your delivery menu prices on Uber Eats align with the prices customers see in-store” and that “Menu markup is calculated based on a comparison of the prices of your most frequently ordered items on Uber Eats to your in-store pricing” (help.uber.com). A chain that fills in_store_price once at onboarding and then raises shop prices twice is scored against a number that stopped being true, and nothing about that field expires or warns.

What does the Uber Eats menu markup metric actually cost you?

Uber frames the answer commercially rather than contractually. It states that “When prices on your Uber Eats menu are noticeably higher than in-store, many customers are likely to abandon their carts or choose alternatives, like not ordering delivery or ordering from other restaurants”, and cites survey data that “If users notice menu markups, only ~22% say they would complete their order through the app” (help.uber.com).

Uber also names a tolerance, saying “The average customer considers a markup of around 10% to be reasonable”. This is the practical difference between Uber Eats and a platform such as Careem Food, which treats a delivery uplift as grounds for removal. On Uber Eats the uplift is permitted and quantified, so the question for an operator is not whether a price is allowed but whether the gap between the app price and the shop price is the gap the brand intended. That is a comparison nobody can run from inside a single platform’s dashboard.

Why can an Uber Eats price land at a hundredth of what you meant?

Because the unit is not the one on the menu board. Uber states plainly that “Price should always be integer value (never decimals) because the price is set in the percent of local currency denomination (e.g., cents for US currency, not dollars)”, and describes price as the “Price of the item in the percent of local currency denomination, e.g. cents and 1/100 for yen” (developer.uber.com). An integration sending 12.5 rather than 1250 is not rejected as malformed, it is a valid integer once truncated, and the item goes live at a fraction of its price.

There is a related trap in the second price field. Uber requires that core_price “Must be >= price”, which means a stale core price can invalidate an otherwise correct reduction, and Uber asks merchants to populate it precisely because it uses that number when something goes wrong with an order: the fields “allow you to provide a signal to Uber Eats on how to best support a customer when problems arise with their orders.”

Which system owns the menu once a POS is connected to Uber Eats?

Uber’s guidance changes as soon as an integration exists. The help article instructs that “If your POS is integrated with your Uber Eats menu, do not submit menu changes using Menu Maker”, and the developer guide tells integrators that if the menu falls out of sync the fix is to “overwrite the menu by uploading a new menu via the API” (developer.uber.com).

The word overwrite is the important one. An Uber Eats menu push replaces the store’s menu rather than amending it, so a manual correction made in Menu Maker survives only until the next scheduled push from the till. Chains that fix a price by hand on Friday and find it wrong again on Monday are usually not looking at a platform fault, they are watching the integration reassert the price that was already in the POS.

How does Uber Eats mark an item you cannot sell?

Uber suspends rather than deletes, and it publishes the customer-facing wording in the API itself. The field suspend_until is documented as “The time at which the item will return to being available for sale, specified as a Unix timestamp in seconds since Jan 1, 1970”, with the note that a null or past value means the item is available and otherwise “it will be shown as “Sold Out” and unavailable to order” (developer.uber.com).

On the tablet, the Uber Eats Orders app offers three states rather than two, labelled “Available”, “Sold Out Today” and “Not Planned to Restock” (help.uber.com). The distinction matters when auditing prices, because an item sitting under a long suspend_until shows no price to anyone, so a pricing error on it stays undiscovered until the timestamp passes and the item returns at whatever price it was carrying.

What should an Uber Eats operator check first when the app price is wrong?

Begin by establishing which of the four price fields is wrong, because a correct price with a stale in_store_price is a scoring problem rather than a customer-facing one, and the two need different fixes. Confirm the value was sent as an integer in minor units. Then check whether the store is POS integrated, since a manual Menu Maker edit on an integrated store is temporary by design. Finally check suspend_until, because an item that shows “Sold Out” is not showing a price at all.

None of that is visible from one screen, which is the practical difficulty. The number a customer is charged on Uber Eats is the product of a default price, a currency convention, an integration schedule and a suspension timestamp. The only place all four resolve into one figure is the live listing. Kitchain (kitchain.co) reads that listing for every branch each day and compares it against the brand’s price book. Ownership, markets and the wider set of Uber Eats signals are covered on the Kitchain Uber Eats page.