Why your EatEasy menu prices differ from the ones you set

Restaurant operators on EatEasy change prices one item at a time, in a back office most of them have never opened, and nothing published says what happens next. Deliverect, an integrator that connects EatEasy, places that back office at manage.eateasily.com rather than on the consumer domain eateasy.ae. The actions its interface calls are per item edits and saves rather than a whole menu publish, which makes EatEasy the mirror image of ToYou, where a single price correction is a full republish that goes through review.

Neither arrangement is safer, they just fail differently. On a platform with per item saves there is no queue to wait in and no batch to inspect, so a wrong number goes live immediately and nothing anywhere produces an error report about it.

Where does an EatEasy price actually get changed?

In the back office at manage.eateasily.com, and Deliverect is the only public source that names the place. Its integration article tells a partner to “Go to https://manage.eateasily.com and log in”, to “Select the Restaurants Preview option in the sidebar”, and to read the identifier next to the “Restaurant Basic Info” header. Nothing further is published by anybody about what else that interface does.

We read what the host serves publicly. On 3 September 2026 the login page returned its front end script without authentication, and that script names the actions the interface calls, including separate edit and save actions for a food item’s details and an action for setting a restaurant’s menu. That is our own reading of public code, not a statement by EatEasy, and it tells us the shape of the tool rather than the rules behind it. What it establishes is that the menu is maintained item by item inside this system, by hand.

The second place a price can come from is a point of sale, and that route is mediated by a person. Deliverect’s instruction ends with the partner passing the restaurant identifier to “your contact person at Deliverect”, who “will then continue the integration process”. So an EatEasy price arrives either from a human editing a screen or from a connection a human configured, and neither path produces a record the brand can query afterwards.

Does an EatEasy price change wait for approval?

Possibly, and this is the honest limit of what we can say. The same public script carries an approvals block, with actions for accepting and rejecting something and a counter of items pending. Something in this system waits to be approved by somebody. What is submitted, whether a price is among it, and how long it takes are not stated anywhere, by EatEasy or by any integrator.

That uncertainty is itself operationally relevant. On ToYou the review is documented and carries a stated ceiling of three hours, so a team knows what to expect and when to escalate. On EatEasy there is no published review, no published turnaround and no status anybody can read, which means a change that has not appeared cannot be classified. It might be waiting, it might have failed silently, and there is no artefact that distinguishes the two.

The practical rule this leads to is unglamorous. Treat an EatEasy price change as unconfirmed until it has been seen on the customer listing, and check it the same day rather than at month end, because the platform provides nothing that will raise its hand.

What happens to an EatEasy price when an integrator publishes a menu?

It is replaced. Deliverect states plainly that publishing menus to a store means “Doing this overwrites the existing menu on your ordering channel”, with the warning to ensure the menu is complete beforehand. On a platform whose back office is a full menu editor, that rule has more force than usual, because there is genuinely a second complete menu sitting on the other side waiting to be overwritten.

This produces the most frustrating class of EatEasy pricing fault, the correction that undoes itself. A branch reports a wrong price, someone with back office access fixes it directly, and the fix holds until the next publish from the point of sale restores the original number. Nobody touched anything, the fault reappeared, and the trigger is a routine job rather than an edit. The same document also requires that “Your store on the ordering channel must be fully set up and working before adding it to your Deliverect account”, which means the hand built menu always exists first and is always the thing that gets replaced.

For a chain the fix is a decision rather than a setting. One system has to be named as the source of truth for EatEasy prices, and everybody has to know which, because the platform will not arbitrate.

How does an EatEasy item come off sale, and why does that look like a price fault?

Through a per item availability action rather than through a price. The public script names an action for setting a restaurant food item available, taking a time related parameter alongside the item identifier, and binds it to an on and off control in the interface. What exact behaviour each value produces is not something we can state, because EatEasy documents none of it and we did not call the endpoint.

The reason this belongs on a page about prices is what a customer sees. An item switched off does not display as unavailable in the way a price displays as wrong, it simply is not in the menu, so a customer comparing your EatEasy listing with your board sees a different offer rather than a different number. Complaints about both arrive worded the same way, and a brand that logs them together will hunt a pricing fault that is actually an availability toggle somebody left on.

The same back office also carries an action for saving deals, so offers are maintained in this system too. That is a second mechanism that changes the price a customer pays without anyone editing the price, and it is worth ruling out before a price investigation starts.

What does EatEasy publish about prices?

Nothing at all. There is no EatEasy price parity position, so whether a delivery price may exceed the counter price is unstated. There is no published tax treatment, in contrast to The Chefz, where an integrator documents both a tax inclusive model and a default rate, which we cover on TheChefz menu price mismatch. There is no propagation figure, no out of stock wording and no error vocabulary. The merchant application on Google Play describes itself in two sentences about orders and offers, and mentions neither menus nor prices.

The gap has a structural cause. Platforms trading in the European Union publish partner terms because Regulation 2019/1150, the Platform to Business rules, requires them to, which is why an operator on Wolt, Glovo, Bolt Food or Just Eat has a document to cite. We have found no equivalent UAE requirement, so nothing we could locate obliges EatEasy to describe its pricing rules, and it does not.

How does a chain verify an EatEasy price without a report?

By reading the customer listing, and by knowing which listing it is reading. EatEasy trades under two domains, the consumer site on eateasy.ae and city listings on eateasily.com, so an audit has to name the surface it checked as well as the branch and the date. Everything else a chain would normally use is missing here. There is no publish log, no error report, no propagation window against which to call a change late and no parity clause to appeal to.

An EatEasy price that was overwritten by a routine publish, or an item quietly switched off, reconciles perfectly inside the restaurant’s own systems, because those systems hold exactly what they last sent, which is why the difference only exists on the storefront that Kitchain (kitchain.co) reads branch by branch each day. The neighbouring question of a store that stopped selling altogether is covered on why an EatEasy store shows as closed, and the platform itself is on the Kitchain EatEasy page.