Why Keeta says your restaurant does not deliver to an address you cover

Keeta publishes no delivery radius at all, and restaurant operators looking for one in its Store API will not find it. What Keeta does document is an override. In severe weather the platform can suspend delivery while leaving pickup running, and the integration guide states that “The store’s overall status remains Open because pickup is still available.” So the listing is not dark and the kitchen is not idle. Customers can still order and collect in person. What has gone is delivery to every address, and only Keeta can restore it.

Downtime readings for Keeta do not describe this failure at all, however low they run. In July 2026 ours were 1.02 percent of stated trading hours lost in the UAE and 0.11 percent in Kuwait. Both figures count stores that were closed. A store in delivery override is not closed by Keeta’s own definition, so every minute of one falls outside the measurement while costing the branch its delivery trade. That is the first thing to understand about coverage on this platform: the availability number and the delivery number are not the same number.

Does Keeta let a restaurant set a delivery radius?

There is nothing to set. The published Keeta Store Management API contains no delivery area object, no radius, no zone identifier and no distance field of any kind. The nine Store endpoints cover status, business hours and store information. The words radius, area and distance do not appear anywhere in the Shop API specification that Keeta publishes for download. Delivery geography on Keeta is entirely a platform matter and is not exposed to the merchant, either through the Keeta Merchant Management Portal or through the API that mirrors it.

The absence is worth stating plainly, because it changes what a support ticket can achieve. On a platform with a radius setting, a district that has gone quiet is at least potentially a configuration question. On Keeta it cannot be. Nothing you can send through the integration describes where you deliver, so nothing you can change through the integration will change it. The only lever is the commercial one, and the only evidence that makes that conversation productive is a record of what customers at those addresses were actually offered.

What is Keeta’s “Platform Override” and when does it apply?

Platform Override is a named section of Keeta’s own store integration guide, headed “3. Platform Override”, and it describes the platform overruling the merchant. Keeta writes: “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.” The stated purpose is rider safety, and the stated method is to take away one service line rather than the whole store.

While an override is in force, the merchant has no route back. Keeta states 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.” Only after that does normal control return, and Keeta spells out the sequence: “Once the platform lifts the override, you can call Reactivate Store to restore full operation.” There is no timer, no expiry and no auto lift documented. The platform decides when it ends.

Does a Keeta override make the store look closed to customers?

No, and getting this right matters more than anything else on this page. Keeta computes the store’s headline status from its two service lines, and the rule is published: the store “is considered Open when either service is available, and Closed only when both are unavailable.” During a delivery override, pickup is still available, so the store is still Open. It is listed, browsable and orderable for collection. The common description of this state as a restaurant that looks open and cannot sell is simply wrong, because a customer standing nearby can order and walk in for it.

What actually breaks is narrower and harder to see. Every customer who wanted delivery, at every address, is turned away, while the store keeps its Open badge and keeps taking collection orders. A dashboard that tracks whether the store is open reports that nothing has happened. The revenue line reports that most of the day has gone. The gap between those two readings is the entire failure mode, and it exists because Keeta chose a design where one status covers two independent services.

Why can Keeta switch off delivery alone when a restaurant cannot?

Because the control is deliberately asymmetric, and Keeta says so. The merchant side has two endpoints, “Suspend Store” and “Store Reactivation”, and both act on everything: the suspend method is documented as “This endpoint will suspend both delivery and pickup at the same time”, and Keeta adds the restriction in plain words, “You cannot independently suspend or reactivate just one service line through the API.” A merchant who wants to stop delivery has to stop pickup too. Keeta itself is under no such limit.

The sub statuses that carry an override are deliveryRestStatus and pickupRestStatus. Keeta describes the first as showing “whether the store’s delivery service is available, unavailable, or not enabled”, with value 2 defined as “Indicates the store’s delivery status is unavailable.” A store in override therefore reads as status 3, Open, with deliveryRestStatus at 2. Keeta also pushes a “Store Status Update Notification” webhook, event 1102, whose payload carries fromDeliveryRestStatus and toDeliveryRestStatus separately from the overall status. A chain with a live integration can see the transition, but only if it listens for that specific pair of fields rather than for the store status alone.

Do the typhoon rules in Keeta’s documentation apply in Dubai and Riyadh?

Do not assume they do. “Typhoons” and “black rainstorms” are Hong Kong terms, black rainstorm being a signal in the Hong Kong Observatory’s rainstorm warning system, and Keeta operates in Hong Kong as well as in the Gulf. The documentation gives those two events as examples of severe weather, not as the complete list, and it does not say which markets the override runs in. Keeta also notes that the split status model itself is regional, describing delivery and pickup sub statuses as something that “some regions” have.

So the honest reading for a Gulf operator is this. The mechanism is documented, the wording of the trigger is drawn from a different market, and Keeta has not published which weather events in the UAE, Saudi Arabia or Kuwait meet the bar. Heavy rain and sandstorms do interrupt road traffic in the Gulf, so the situation the override was written for is not foreign to the region. Whether Keeta applies the override here, and at what threshold, is not something its documentation answers, and we are not going to fill that gap with a guess.

How does a Keeta operator tell an override apart from an ordinary suspension?

From outside, by what the storefront offers rather than by whether the storefront exists. An ordinary suspension takes the store off the app entirely and holds it there until a person reactivates it, which is the separate failure we set out on why a suspended Keeta store stays hidden. An override does the opposite and leaves the store visible with delivery stripped out of it. So the check is not whether the branch is listed but whether the branch is orderable for delivery to a specific address, and those two questions give different answers only in the case that costs the most money.

A Keeta override never produces an offline store, so availability monitoring alone will never surface it. The state has to be read from the delivery option offered at a real address, which is the reading Kitchain (kitchain.co) Coverage takes from the customer side at kitchain.co. The rest of what we watch on this platform, and how it behaves across the Gulf, is set out at https://kitchain.co/aggregators/keeta/.