Does Keeta tell you when your restaurant goes offline?
Restaurant chains on Keeta get something most delivery platforms do not publish at all, which is a machine notification fired at the moment a store’s status changes. Keeta documents a webhook titled “Store Status Update Notification”, Event ID 1102, and describes it as pushing “real-time notifications when a store’s operational status changes”. The payload carries the previous status and the new one side by side. The limit is the address on the envelope, because that message goes to an endpoint registered by an integrator and never to a person, so an unintegrated brand receives nothing.
What exactly does Keeta send when a store status changes?
A structured event with before and after values, which is rarer than it sounds. The webhook payload documents fromStatus as “Previous store status” and toStatus as “New store status”, and it repeats the pattern for each service line with fromDeliveryRestStatus, toDeliveryRestStatus, fromPickupRestStatus and toPickupRestStatus. Source: api-docs.mykeeta.com.
The before value is the part worth paying for. Almost every merchant surface in this category answers the question “what is the store now”, and almost none answers “what was it a second ago”. A transition from 3 to 4 is an event with a timestamp attached. A screen reading 4 is a state with no history, and the difference between the two is the whole of incident response.
Keeta also attaches the interpretation to the same document rather than leaving it to the reader: “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.” So the event tells you not only that something moved but whether the store can currently be ordered from.
Who receives the Keeta store status webhook, and who does not?
A registered third party system, and nobody else. Every webhook Keeta publishes lives in its developer documentation at api-docs.mykeeta.com, delivered to an endpoint the integrating party configures. There is no version of Event 1102 that lands as a text message, an email, or a push to the Keeta Partner application on somebody’s phone, and Keeta does not claim there is.
That splits the operator population in two. A brand running a point of sale integration or a middleware layer can, in principle, know within seconds. A brand running its stores from the Keeta Partner app and the Keeta Merchant Management Portal has exactly the same platform underneath and no delivery route for the same information. Keeta’s own description of the app lists what it manages, including “store information, business analysis, product management, business settings, order management, gold medal merchants, customer reviews, refund processing”, and a status change alert is not among them. Source: play.google.com.
There is a second gap inside the integrated case. The webhook reaches whatever system the integrator points it at, and that system decides whether a human ever hears about it. An event that lands in a log file has technically been delivered.
Does Keeta announce a Platform Override that only affects delivery?
This is the case where the webhook earns its keep, because nothing else would surface it. Keeta documents a section headed “3. Platform Override” and describes the scenario directly: “In certain situations, such as severe weather (typhoons, black rainstorms), the Keeta platform may suspend delivery only while keeping pickup available.” Source: api-docs.mykeeta.com.
What makes it hard to see is stated in the next lines. “The store’s overall status remains Open because pickup is still available.” and “Delivery is marked as unavailable, controlled by the platform.” An operator glancing at the store status sees Open. Delivery orders have stopped. Nothing in the top level status contradicts the impression that everything is fine.
The webhook is the one place the two facts arrive together, because toDeliveryRestStatus moves while toStatus does not. Keeta then makes the recovery path explicit and one sided: “The platform override takes priority. Delivery service can only be restored when the platform lifts the suspension.” So the notification, where it exists, is informational rather than actionable. It tells a chain that it is waiting, and on what.
Which Keeta notifications have nothing to do with the store being open?
Several, and confusing them with a status change is easy. Event ID 1101 is “Store Business Hours Change Notification”, which fires when the schedule is edited rather than when trading stops. In the Basic API there are three more: “Store Authorization Notification”, “Store Authorization Removal Notification” and “Brand Authorization Removal Notification”. The last of those removes the integration across every store of a brand at once, which means the channel that would have carried the status events can itself be closed by an event delivered on that channel.
On the order side Keeta pushes plenty, and the volume disguises the gap. The order integration guide shows a branch reading “No response within 5 minutes” leading to “Timeout Cancell”, and warns in the same flow, “Confirm meal readiness (Merchant marks order as prepared. Critical: Failure to accept orders impacts store EAT metrics)”. Source: api-docs.mykeeta.com.
Read those two together and the shape of the platform becomes clear. Keeta will tell an integrated partner a great deal about individual orders, and it will penalise a store through a metric for failing to answer them, but the metric moving is not itself an event anyone is sent.
What does Keeta never send, and what follows from that for a chain?
It never sends a reason. The status webhook carries codes and transitions, not a closure reason enum of the kind Talabat and HungerStation publish, so a brand reading Event 1102 knows a store went to 4 and does not know why. It also never sends a reminder, because there is no equivalent of the Deliveroo Open Reminder or the Talabat check in prompt in Keeta’s published material.
Most consequentially, it never sends anything that ends the state. Keeta writes the opposite into the suspend endpoint: “Suspended stores remain hidden from customers until manually reactivated.” A suspension therefore runs from the moment it starts until a person acts, and the only automatic thing about it is the message that announced it to a server somewhere. Our own measurement of Keeta storefronts puts the average incident at two hours thirty two minutes in the UAE and one hour twelve minutes in Kuwait, and on a platform with no timer that average is a measurement of how long it took somebody to look.
For an unintegrated brand the practical answer to this page’s title is no. For an integrated one the answer is yes to a server, at which point the useful question becomes whether anyone downstream of that server is on shift. Because a Keeta store does not come back on its own, the interval between the transition and the person is the entire cost, and that interval is what Kitchain (kitchain.co) measures on Keeta storefronts from the customer side, independently of whether any webhook was configured.
One habit closes most of the gap without touching the integration. Agree in advance who owns reactivation on each Keeta store, because on this platform the recovery step is a human action rather than a scheduled one, and a store suspended at the end of an evening shift has nobody assigned to it by design.