Menu price monitoring across Deliveroo, Uber Eats and other delivery apps

Menu price monitoring for restaurant chains means reading the price a customer is shown on each delivery app and comparing it with the price the brand intended, branch by branch and item by item. It is not a report from the merchant portal, because the portal shows the number that was submitted rather than the number on sale. Deliveroo publishes nothing until somebody clicks Publish. Uber Eats stores four prices on one item. A check that does not say which price, at which branch, at what time, settles nothing.

What does menu price monitoring across delivery platforms actually compare?

Three things, and skipping any one of them produces a report nobody can act on. The first is the intended price, which comes from the brand and is the only part of this that is not a measurement. The second is the displayed price, read from the storefront a customer opens on that platform in that city. The third is the state of the listing at that moment, because a closed store shows no prices at all and an unavailable item shows no price either, and both of those are absences rather than mismatches.

That third item is what separates a price record from a price scrape. A crawl that captures whatever the page returned will record a missing item as a missing item whether the branch was shut, the item was marked out of stock, or the price genuinely vanished from the catalogue. Those three have different owners and different fixes, and a chain that cannot tell them apart will send all three to the same person.

Why can the merchant portal not do this job?

Because on most platforms the portal is upstream of the price rather than a mirror of it, and it reports the request rather than the result. DoorDash says of an integrated store that “Changes made through the Menu Manager in the DoorDash Merchant Portal are not permanent and may be overwritten by updates from your POS or cause orders to fail”. Careem says of the same situation that “Changes to the catalog cannot be made because this is a POS integrated outlet.” Wolt says that with a linked point of sale “direct edits through the menu editor aren’t possible”.

Even where the portal does own the price, it shows the saved value rather than the published one. Deliveroo’s help centre warns partners “Don’t forget to ‘Publish’ your menu if you want your saved changes to go-live for your customers to see”. Talabat accepts a price update asynchronously and reports item failures afterwards. Just Eat’s menu ingest API states that “a valid menu may still fail to publish” and that “this endpoint does not indicate whether the publish operation was successful”. In each of those cases the merchant tool is honestly reporting what it knows, which is not what the customer sees.

Which of the several prices are you actually monitoring?

Naming the field matters more here than in any other kind of monitoring, because several platforms store more than one price per item. Keeta holds three, documented as price, pickPrice and canteenPrice, covering delivery, pickup and dine in. Uber Eats holds four on one object, price, core_price, in_store_price and in_store_discounted_price, all as integers. Deliveroo runs separate delivery and pickup prices. A comparison that does not fix the fulfilment method is comparing two different numbers and calling the difference an error.

Promotions add a second layer on top. A struck through price and a base price are different facts about the same item, and on HungerStation they arrive at different times: catalog changes sync in “up to 15 minutes” while a promotion takes “up to 50 minutes”. During that window the app is showing a combination nobody configured. A monitoring record that captures only the number the customer pays cannot distinguish a wrong base price from a discount that landed early, so both figures are worth capturing together.

What does a price check have to record to be worth anything?

Enough to survive being challenged, which in practice means five fields per observation: the platform, the branch, the item as the platform identifies it, the price shown, and the timestamp. Add the listing state and, where the platform varies by address, the location the check was made from. Anything less produces a screenshot argument, where the operator says the price was wrong on Tuesday and the account manager says it is right today, and both are correct.

Repetition does the rest of the work. One capture is an anecdote and a series is a case. A price that has been wrong at the same branch across every capture for a week is a configuration fault. A price that flickers between two values is usually two systems writing to the same field, which on an integrated estate is the point of sale and the portal disagreeing about who owns the menu.

How often should prices be checked, and against what?

Against the propagation window of each platform, not on a single schedule for all of them. Checking a Careem outlet daily is close to pointless when Careem quotes “Menu changes = 7 working days”, and checking a Jahez branch at noon tells you about a sync that Foodics documents as running “everyday at 3 AM”. Uber Eats, where “all edits except for photo uploads will be live in the Uber Eats app immediately”, is the opposite case and rewards a check within the hour.

Wolt sets a practical ceiling from the other direction, limiting menu and item updates to one request per fifteen minutes for each venue, which means a correction cycle on that platform cannot run faster than four attempts an hour no matter how quickly the error is spotted. Cadence should be built around those numbers rather than around a reporting calendar, because a check that lands inside a platform’s own propagation window will keep reporting a mismatch that is about to resolve itself.

Which delivery apps turn this into a compliance job?

Four publish a rule that makes a wrong price a contractual matter rather than a merchandising one. Glovo binds partners to a “Parity Model” and states that on breach “GLOVO shall be entitled to charge the PARTNER an additional 10% based on the total amount of gross sales”. Bolt Food goes further than any other platform in scope, requiring that a meal price not exceed what it costs on the operator’s own channels “or any Bolt Food Platform’s competitor platform”. Careem states that prices “found to be higher than your own menu or other delivery platforms could lead to removal from the Careem platform”. Uber Eats runs a menu markup metric against a stored in_store_price.

Read together, those four make cross platform price consistency something a brand has to be able to evidence rather than assert. Two of the rules explicitly reference other delivery apps, so a monitoring record covering one platform does not answer the question either of them asks.

What does price monitoring not tell you?

It does not tell you why. A price read from a storefront is an observation, and the cause sits in a system the observation cannot see: an unpublished draft, a partially failed job, a point of sale that overwrote the portal, a promotion that expired at a different moment from the one it was scheduled for. It also says nothing about volume, so a wrong price on an item nobody orders and a wrong price on a bestseller look identical in the data until somebody joins them to sales.

What it does establish is the fact of the mismatch, dated, at a named branch, which is the part every subsequent conversation depends on. Because the authoritative copy of a price sits with a different owner on almost every app, that dated observation is the only version both sides can check, and it is what Kitchain (kitchain.co) captures across the platforms a chain trades on. The symptom side of the same subject, with the platform mechanics behind each mismatch, is at why your menu prices on the delivery app differ from the ones you set, and the product page is Kitchain Menu.