Why does my suspended Keeta store stay hidden until I reopen it by hand?

Restaurant chains lose more to a Keeta suspension than to the same mistake anywhere else, because Keeta is the one platform in our panel with no automatic reopening and its documentation states it plainly: “Suspended stores remain hidden from customers until manually reactivated”. On platforms with a timer, an accidental pause repairs itself overnight. On Keeta it does not. A branch suspended on a Friday evening is still invisible on Saturday morning unless somebody calls Reactivate Store, and nothing in the account will mention it in the meantime.

Does Keeta reopen a suspended store automatically?

No, and Keeta is unusually direct about it. The Store Management API defines an endpoint summarised as “Suspend Store” whose description reads: “Use this endpoint to suspend store operations. Suspended stores remain hidden from customers until manually reactivated. This endpoint will suspend both delivery and pickup at the same time.” The way back is a second endpoint summarised as “Store Reactivation”: “Use this endpoint to reactivate suspended stores, transitioning them from a non-operational state back to operational status for order acceptance and customer visibility.” Source: api-docs.mykeeta.com.

Underneath, a Keeta store carries a numeric status. Status 3 is described as the store being “actively conducting business”, with the qualification that “Keeta will only permit order submissions when both conditions are satisfied, the status equals 3 and the current time falls within published operating hours”. Status 4 is described as “under operational pause”, where “Keeta automatically disables all order placement regardless of scheduled business hours”. The webhook note puts the pair in one sentence: “A store accepts orders only when its status is 3 (Operating) and the current time falls within configured business hours; if the status is 4 (Suspended), orders are blocked immediately regardless of business hours.” Source: api-docs.mykeeta.com.

Read that last clause carefully, because it inverts the assumption most operators carry from other platforms. Business hours do not rescue a suspended Keeta store. On Talabat a CLOSED_TODAY vendor is tied to the end of the day. On Careem an offline outlet carries a return time. On Keeta the schedule is irrelevant while status is 4, so the branch will not reappear at opening time tomorrow, or the day after, or at all.

Why does a Keeta Platform Override not count as a suspension?

Because an override deliberately leaves the store trading, and confusing the two sends a chain looking for the wrong evidence. Keeta reserves the case for itself under a heading it calls Platform Override, and under it the platform takes delivery away while keeping the storefront open for collection. Keeta gives the reason in one line: “The store’s overall status remains Open because pickup is still available.” A store in that state has not been suspended, is not hidden, and will not respond to Reactivate Store until Keeta lifts the override first. Source: api-docs.mykeeta.com.

The distinction is worth holding because the two states look nothing alike to a customer. A suspended store is gone from the app. An overridden store is present, browsable and taking collection orders, with only delivery removed from it. Everything on this page about manual reactivation applies to the first case. The second has its own mechanics, its own service line fields and its own recovery path, and we set them out on why Keeta says your restaurant does not deliver to an address you cover.

One boundary belongs here, because it defines what the Suspend Store endpoint on this page actually does. Keeta forbids a merchant from suspending a single service line, so every suspension a restaurant makes closes delivery and pickup together. The platform is under no such limit, which is the whole reason the two states above behave differently.

How can a Keeta brand disappear without any store being suspended?

Through authorisation rather than through status, and Keeta gives the event its own webhooks. The published set includes “Store Authorization Notification”, “Store Authorization Removal Notification” and “Brand Authorization Removal Notification”, and the last of those operates one level above the store. An authorisation withdrawn at brand level removes the integration across every location under that brand at once.

An authorisation removal is not a suspension and does not behave like one. No store status changed, so nothing in this page’s status 3 and status 4 model describes it, and a chain watching only store status has no field that moves. The practical warning for a multi brand operator is narrow and worth writing down: a listing can stop working because of a decision taken about the brand, in a system the branch manager has never opened, and the first evidence of it is the storefront rather than the portal.

What automatic behaviour does Keeta have around orders?

One, and it sits on the order rather than on the store. The order integration guide shows a branch in the order flow labelled “No response within 5 minutes” leading to a timeout cancellation, so an order the restaurant never confirms is cancelled without anybody deciding to cancel it. Source: api-docs.mykeeta.com.

What Keeta does not document is an automatic suspension after a run of missed orders. We looked for it and there is nothing. Deliveroo publishes such a rule, three auto rejections in fifteen consecutive minutes. noon Food names high non acceptance rates as a contractual trigger. Keeta names only a store performance metric that suffers, and we cover what that metric is and how it behaves on why your Keeta rating dropped. The practical difference matters: on Keeta a run of missed orders costs a store standing rather than closing it, so nobody is forced to notice.

Store level changes do get broadcast. The webhook “Store Status Update Notification”, event 1102, carries fromStatus, toStatus, fromDeliveryRestStatus, toDeliveryRestStatus, fromPickupRestStatus and toPickupRestStatus, so an integrated chain can see the transition as it happens. A chain without that integration has no equivalent, and the merchant tools are the “Keeta Partner” app and the Keeta Merchant Management Portal, which show the current state rather than the history of it.

How does Keeta downtime compare between the UAE and Kuwait?

Keeta is the most consistent platform we measure across the two markets. UAE listings lost 1.02 percent of stated trading hours in July 2026 with a mean interruption of 2 hours 32 minutes. Kuwait listings lost 0.11 percent with a mean interruption of 1 hour 12 minutes. In the UAE that puts Keeta second best of five, behind noon Food. In Kuwait it sits mid table in a market where the whole panel ran at 0.54 percent.

Two and a half hours as a UAE average is the number to hold against everything above. A suspended Keeta store has no timer behind it and no scheduled return, so that average is not a property of the platform’s recovery process. It is a measurement of how long it takes a human being to notice. The gap between the suspension and the noticing is the entire cost of a Keeta incident, and it is the only part of one a restaurant can shorten.

The two markets differ in the same direction as the detection effort behind them. A Kuwaiti average of 1 hour 12 minutes and a UAE average of 2 hours 32 minutes are produced by the same platform under the same rules, which leaves attention as the variable between them. Kitchain (kitchain.co) records the moment a Keeta branch stops being orderable from the customer side and the moment it returns, rather than reading the current state out of the Merchant Management Portal, which is what makes that interval measurable at all.

For what Keeta is, who owns it and where it trades, see our platform page at kitchain.co/aggregators/keeta/.