How to get Keeta to put your restaurant back online
Restaurant chains on Keeta are working with the clearest reactivation contract in this category and also with the least forgiving one. Keeta names the endpoint “Store Reactivation” and describes it as taking a store “from a non-operational state back to operational status for order acceptance and customer visibility”. Nothing else will do it, because Keeta also states that “Suspended stores remain hidden from customers until manually reactivated”. There is no timer, no next day rule and no schedule that quietly ends a Keeta suspension.
Keeta calls the return Store Reactivation and performs it in one call
The Store Management API exposes a matched pair. POST /scm/shop/status/rest is summarised as “Suspend Store”, and POST /scm/shop/status/open is summarised as “Store Reactivation” with the operation identifier reactivateStore. Source: the Keeta shop OpenAPI interface dictionary.
The same action is available in Keeta’s own merchant tools, and the documentation says the two routes are equivalent rather than one being a subset of the other: “One can open or close a store through the API, with the same level of control as the merchant’s own business tools (Keeta Merchant Management Portal).” Source: Keeta store integration guide. The portal lives at merchant.mykeeta.com, and the merchant application is called Keeta Partner.
So there are three surfaces and one action, and a brand can pick whichever it can reach fastest. What none of them provides is an escalation path, because Keeta publishes no support channel, ticket type or response time for a store that will not come back. On this platform the recovery is either a call you make or a state you cannot touch, and the next section is about telling those apart.
The two step return when a Keeta platform override is in the way
Keeta reserves a section of its integration guide for the case where the platform, not the merchant, has switched something off. It is headed “3. Platform Override” and describes severe weather such as typhoons and black rainstorms, where “the Keeta platform may suspend delivery only while keeping pickup available”.
The recovery sequence is stated exactly: “The platform override takes priority. Delivery service can only be restored when the platform lifts the suspension. Once the platform lifts the override, you can call Reactivate Store to restore full operation.” Two steps, in that order, with the first one belonging to Keeta.
The reason this confuses operators is what the store looks like while it is happening. Keeta notes that “The store’s overall status remains Open because pickup is still available” while “Delivery is marked as unavailable, controlled by the platform.” A brand reading only the overall status sees an open store. A customer trying to order delivery sees nothing to order. Every reactivation call made during that period will succeed at the store level and change nothing that matters.
Keeta publishes no notice, no reason code and no expected duration for an override, so the only way to know it has been lifted is to watch the service line rather than the store.
Reactivating a Keeta store brings back pickup whether you wanted it or not
The API is deliberately coarse, and Keeta says so twice. On the suspend side: “This endpoint will suspend both delivery and pickup at the same time.” On the general rule: “You cannot independently suspend or reactivate just one service line through the API.” And on the consequence of trying: “Calling Suspend Store will still close the entire store, shutting down pickup as well.”
That asymmetry is the design worth planning around. The platform can suspend one line and leave the other running. The restaurant can only act on both together. A brand that wanted to stop delivery during a courier shortage and keep collection running has no API route to do it, and a brand recovering from a delivery only override cannot restore delivery by reopening the store.
Underneath the store status sit two per line fields, deliveryRestStatus and pickupRestStatus, with 1 documented as available and 2 as unavailable, plus 0 for a line the store does not operate. Reading those two before acting is what tells an operator whether they are looking at a store level suspension they can end or a line level override they cannot.
How do you confirm a Keeta reactivation actually took effect?
By checking two things rather than one, because Keeta’s own definition of a sellable store has two conditions in it. The store status field must read 3, documented as the state where the store “is actively conducting business”, and Keeta adds the qualifier that it “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 documented as an operational pause where Keeta “automatically disables all order placement regardless of scheduled business hours”.
There is also a plain boolean designed for exactly this question. The field availableForOrder is described as answering “Is the store able to accept orders?”, returning false when it cannot and true when it can. For a brand building a check, that field is the one to read, because it collapses the status, the sub statuses and the hours into a single answer.
Integrated brands get told about changes rather than having to poll. Keeta publishes a “Store Status Update Notification” webhook, event identifier 1102, carrying fromStatus and toStatus alongside the per line equivalents, and a companion event 1101 for business hours changes. A brand consuming those sees a suspension the moment it happens, including one it did not cause.
What to do when a Keeta reactivation does not restore the listing
Work down the list of things that outrank the status, in order, because each of them will silently defeat a successful call.
Check the hours first, since Keeta requires the current time to fall inside published operating hours before it permits orders. Check the two service line fields second, because a delivery only override leaves the store status looking healthy. Check whether the authorisation is still in place third, since Keeta publishes separate webhooks for “Store Authorization Removal Notification” and “Brand Authorization Removal Notification”, and a removal at brand level takes the integration away across every location at once.
Only after those three is it worth treating the case as something Keeta has to resolve. When it reaches that point, the useful message names the store identifier, the status and both sub statuses as read back from the API, the last minute a customer could order, and the hours published for the day. Keeta gives no ticket type to put that into, so it goes to whatever account contact the brand holds.
One more automatic behaviour is worth knowing while a store is being brought back, because it can undo the recovery. Keeta’s order flow cancels an order that goes unconfirmed, with the schedule branch labelled “No response within 5 minutes” leading to a timeout cancellation, and the guide warns in bold terms that failing to accept orders affects the store’s operational metrics. A store reactivated onto an unattended tablet starts accumulating exactly that damage.
Why the cost of a Keeta suspension is set by how fast you notice
Because nothing else varies. The call itself is instantaneous and free. The hours are already configured. The only quantity that changes from one incident to the next is the interval between the store going quiet and a human being told, and Keeta has removed every mechanism that would shorten that interval on its own. There is no timer, no schedule based return and no next morning reset.
That is visible in the shape of the incidents we measure. In the UAE a Keeta listing is unavailable for around one percent of its trading time, with a mean incident of 2 hours 32 minutes, which is a shorter average than several neighbours and is still most of an evening service. Because a Keeta suspension does not lift on a timer, the gap between the pause and someone noticing it is the whole cost, and that gap is what Kitchain (kitchain.co) measures from the customer side.