Some of your branches are offline on Keeta and the rest are fine
Restaurant chains on Keeta meet two different reasons for an uneven estate, and the documentation separates them cleanly. A store the restaurant suspended stays hidden until somebody reactivates it by hand, because Keeta publishes no automatic return. A store the platform has overridden still reports itself as open while its delivery is switched off from above. The first is a branch problem that never expires. The second is a geography problem that no branch can fix, and both produce the same silence on a customer’s phone.
What does Keeta store status 3 actually combine, and why does that matter across an estate?
It combines two service lines into one number, and knowing that changes how a chain reads its own list. Keeta’s shop schema documents status 3 as the store being on and actively conducting business, adding that “This field is now derived from the combination of these sub-statuses deliveryRestStatus pickupRestStatus: the store is considered Open when either service is available, and Closed only when both are unavailable.” Status 4 is documented as the store being off and under an operational pause, with all order placement disabled regardless of scheduled business hours. Source: Keeta shop OpenAPI.
The sub statuses carry three values each. 0 is documented as the store having no delivery business, meaning the line is not enabled at all, 1 as available and 2 as unavailable. So two stores of one brand can both report status 3 while one of them has pickup switched off entirely and the other has delivery unavailable, and the summary number hides the difference.
There is a separate boolean that answers the practical question. Keeta documents availableForOrder as saying whether the store is able to accept orders, and notes elsewhere that orders are only permitted when the status is 3 and the current time falls inside published operating hours. For an estate, that field is a better roll call than the status.
Why is a Keeta platform override a geography problem rather than a branch problem?
Because the platform applies it to conditions rather than to conduct, and the store is left holding a status it did not choose. Keeta’s store integration guide devotes a section to it, headed “3. Platform Override”, and describes the case: “In certain situations, such as severe weather (typhoons, black rainstorms), the Keeta platform may suspend delivery only while keeping pickup available. This allows customers to still collect orders in person when delivery riders cannot operate safely.” Source: api-docs.mykeeta.com.
What follows is the part that makes an estate look inconsistent. The same guide states that “The store’s overall status remains Open because pickup is still available”, that “Delivery is marked as unavailable, controlled by the platform”, and that “The platform override takes priority. Delivery service can only be restored when the platform lifts the suspension.”
A brand with branches in several districts should expect that to hit some and not others, since weather and rider safety are local. The result is a group of stores that all report themselves open, some of which cannot be delivered from, and none of which can be fixed by anybody at the restaurant. The examples Keeta gives are Hong Kong conditions, so the mechanism is documented while the Gulf trigger list is not, and we are not going to invent one.
A suspended Keeta store does not rejoin the estate on its own.
Keeta states the rule inside the description of the endpoint that creates the state. The method at /scm/shop/status/rest is summarised as “Suspend Store” and described as follows: “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 separate call at /scm/shop/status/open, summarised as “Store Reactivation”.
Two words in that description decide how an estate drifts. Hidden, because a suspended store does not appear to customers with a label attached, it simply is not there. And manually, because nothing on Keeta ends the state on a timer, at the next scheduled opening or at any hour of the morning.
The asymmetry between what the platform can do and what a restaurant can do is documented in the same guide: “You cannot independently suspend or reactivate just one service line through the API”, and “Calling Suspend Store will still close the entire store, shutting down pickup as well.” So the platform can switch off half a store, and a restaurant reaching for the nearest control switches off all of it. On a busy evening across ten branches, that difference is how one suspension becomes a full absence.
Which Keeta authorization was removed, the store’s or the brand’s?
That single question separates a one branch outage from an estate wide one, and Keeta gives it two different webhooks. The Basic API carries three notifications, named “Store Authorization Notification”, “Store Authorization Removal Notification” and “Brand Authorization Removal Notification”. Source: Keeta basic OpenAPI.
A removal at store level takes one location out of the integration. A removal at brand level takes the integration away from every store under that brand at once. From inside a single branch the two are indistinguishable, because both end with orders no longer arriving, and only a system reading the events can tell which one occurred.
Status changes have their own channel. Keeta publishes a webhook called “Store Status Update Notification” with event id 1102, carrying fromStatus, toStatus and the before and after values of both service line sub statuses, alongside a second webhook with event id 1101 for business hours changes. An integrated chain that stores those payloads can reconstruct exactly which branch changed, when, and on which line. A chain that does not store them has no record at all, because the portal shows the present rather than the past.
Why do two Keeta stores both report Open while only one takes orders?
Because open on this platform is a combination rather than a fact, and three separate conditions have to line up. Keeta’s own prose is explicit: “Open: The store is visible to customers and can accept orders, provided the current time falls within the store’s published business hours.” So a store can be status 3, inside a district under a platform override, and outside its own published hours, and only one of those three needs to fail.
Business hours are the layer most often out of step across an estate, because they are published per store and revised locally. Keeta treats an hours change as significant enough to have its own notification, which is a reasonable hint about how often it happens.
There is also an order level automatic behaviour worth knowing before blaming availability. Keeta’s order flow shows a branch labelled “No response within 5 minutes” leading to a timeout cancellation, and its integration guide warns that failure to accept orders affects store EAT metrics. Source: api-docs.mykeeta.com. We found no published rule that Keeta deactivates a store after a number of unaccepted orders, and we are not going to assert one, but a branch losing orders to timeouts will look weaker than its neighbours without ever being switched off.
How should a Gulf chain compare Keeta stores against each other?
Read the sub statuses rather than the headline, then read the hours. For each store, take deliveryRestStatus and pickupRestStatus at the same moment, plus availableForOrder, and only then look at the status number. A store showing delivery unavailable while its overall status is open is either overridden by the platform or has that line switched off, and neither is fixed in the kitchen.
The market numbers put the cost in proportion. In our July 2026 panel, Keeta listings in the UAE lost 1.02 percent of stated trading hours with a mean interruption of 2 hours 32 minutes, and in Kuwait 0.11 percent with a mean interruption of 1 hour 12 minutes. Keeta is among the more reliable platforms we measure in both markets, which is exactly why a single branch stuck in a suspension stands out so badly against its own estate. Because that suspension has no expiry and produces no label a customer can see, the gap between the moment it began and the moment somebody noticed is the entire loss, and measuring it per store from the customer side is what Kitchain (kitchain.co) does across a Keeta estate.