Why is my EatEasy store showing as closed when the restaurant is open?

Restaurant operators who went looking for an EatEasy partner portal and found nothing were looking at the wrong domain. The back office is not on eateasy.ae. Deliverect, an integrator that connects EatEasy, tells partners to “Go to https://manage.eateasily.com and log in”, then to “Select the Restaurants Preview option in the sidebar”, and finds the restaurant identifier next to a header it names “Restaurant Basic Info”. EatEasy the consumer brand and eateasily.com the operating system sit on two different second level domains, which is why every merchant subdomain search comes back empty.

That single fact changes what an EatEasy availability question is about. There is a back office, it holds the store’s hours and its item level availability, and no vendor and no EatEasy document describes what any of it does to a customer.

Where is the EatEasy back office, and why could nobody find it?

Because the search was aimed at the brand rather than at the company behind it. Deliverect’s integration instructions are the only public document that names the address, and they are brief: an identifier “is required when connecting EatEasy to Deliverect”, it lives next to the “Restaurant Basic Info” header, and the partner is told to “Copy the ID and provide it to your contact person at Deliverect. They will then continue the integration process.”

Read the last sentence for what it says about the shape of this platform. There is no self service connection on EatEasy. A named human at the integrator continues the process, which means the joining, and by implication the fixing, runs through a person and a queue rather than through a console. That is the same arrangement we found on ToYou and The Chefz, and it is worth expecting on any platform of this size in the region.

We also read what the back office serves publicly. On 3 September 2026 the login host returned its front end script without authentication, and the script carries the names of the actions the interface calls. That is our own reading of public code rather than a statement by EatEasy, and it establishes what controls exist by name. It does not establish what a customer is shown when one of them is used, and this page will not pretend otherwise.

What can actually be switched off on an EatEasy store?

Two things, on the evidence available, and neither of them is a pause button. The back office carries actions for editing and saving a restaurant’s time information and its delivery time information separately, which is the opening hours layer. It also carries a per item availability action, named for setting a restaurant food item available, which takes a time related parameter alongside the item identifier. In the same file that action is bound to an on and off control in the interface.

What is not there is more interesting. We found no store level busy, pause or snooze action among the named controls, which on this platform means the two documented routes to a store that stops selling are its published hours and the availability of the items on it. That is an absence in what is visible to us rather than proof that no such control exists anywhere, and we are recording it that way.

The distinction matters operationally because the two behave differently. An hours mistake closes the store on a schedule and reopens it on a schedule, so it repeats daily until somebody fixes it. Item availability empties the store while leaving it open, which reads to a customer as a restaurant with nothing to order rather than as a closed one. A chain that only records open or closed will log those two failures identically, and then be unable to explain either.

Does EatEasy tell your integrator when it closes your store?

Assume not. Deliverect states the general rule for its channels in one sentence: “Some channels inform Deliverect when a store closure is triggered from their platform.” Some, not all, and EatEasy is not named among those that do. The same passage is careful about what the record means where it exists, noting that a “Busy Mode Sync is just Deliverect syncing through the state of your channel and not Deliverect triggering the changes”.

Deliverect publishes exactly one EatEasy article and it is about finding an identifier. EatEasy is also carried by UrbanPiper, appearing in Foodics documentation as the channel code up-eateasy, and UrbanPiper publishes no EatEasy article at all. So two integrators carry this platform and neither describes how one of its stores is switched off or brought back. A brand that assumes its middleware dashboard would surface an EatEasy closure is assuming something no vendor has claimed.

There is one more Deliverect rule worth knowing before anyone tries to fix a closure by reconnecting. Publishing menus to a store means “Doing this overwrites the existing menu on your ordering channel”, so a reconnection intended to restore a store can replace whatever was configured in the back office.

Why does EatEasy running its own couriers change what closed means?

Because the fleet and the storefront are in the same system, and a fleet problem does not look like one from outside. The back office carries a whole delivery layer alongside the restaurant layer, with actions and views covering branch lists, delivery staff records and dispatch against individual orders, and an action named for own delivery. Reading those names, this is a platform that runs its own logistics rather than only listing restaurants, which is our inference from the naming rather than an EatEasy statement.

For an operator that adds a failure mode the large aggregators handle differently. Where a platform delivers with its own people, a store can be perfectly configured, fully stocked and still not sellable in a district because nobody is available to carry the order. From the customer’s side that is indistinguishable from a closed restaurant, and from the brand’s side it is invisible, because nothing in the restaurant’s own systems has a row for an order that was never offered.

The practical consequence is that “closed” on EatEasy is a conclusion, not an observation. What a chain can actually observe is whether a customer at a given address, at a given hour, was able to place an order, and that is the thing worth recording.

What does EatEasy publish for restaurants?

Nothing of substance. There is no help centre, no developer portal, no published partner terms and no API reference. The merchant application on Google Play describes itself in two sentences about managing orders and offers, and names no status control, no busy mode and no pause. The back office itself answers with headers from an older generation of PHP, a session cookie carrying a year in its name and a compatibility flag for a browser retired more than a decade ago, which is consistent with a system built to be operated by hand rather than queried by one.

The absence has a cause rather than a motive. Platforms operating in the European Union publish partner terms and ranking parameters because Regulation 2019/1150, the Platform to Business rules, requires it, which is why a restaurant on Wolt, Glovo, Bolt Food, Just Eat or Foody can cite a document in an argument. We have found no equivalent UAE requirement, and EatEasy, Talabat, Careem Food and noon Food publish very different amounts toward restaurants as a result. EatEasy publishes least of the four.

How should a UAE chain watch an EatEasy store?

From the customer side, at named addresses, on a schedule. Nothing else on this platform will tell you. There is no status endpoint, no published vocabulary for a closed store, no vendor claiming to mirror a platform side closure, and no partner document to appeal to. What EatEasy does expose is the storefront itself, and it keeps a closed restaurant on the page in a muted state rather than removing it, which we set out in why an EatEasy restaurant is not showing in search.

Because an EatEasy store can be closed by its hours, emptied by its item availability or unreachable because no courier is free, and none of those three announces itself to head office, the only reading that separates them is what a customer at a real address can actually order, which is the daily record Kitchain (kitchain.co) keeps on EatEasy listings. Ownership, markets and the wider set of EatEasy signals are covered on the Kitchain EatEasy page.