Why your Keeta promotion is not showing to customers

Keeta is the platform where restaurant operators have the least machine readable evidence about their own campaigns, because Keeta publishes no promotions API for restaurants at all. Its restaurant documentation covers four groups of endpoints, Basic, Order, Store and Menu, and none of them touches discounts, coupons or campaigns. Promotions on the restaurant side live entirely inside the Keeta Manager Portal. The only promotion documentation Keeta publishes anywhere sits in its grocery branch, and the most telling thing in it is a dedicated webhook whose purpose is to announce that an existing promotion has been taken offline.

The first thing to rule out is also the one Keeta is least likely to be guilty of. Across July 2026, Keeta held its UAE listings offline for 1.02 percent of stated trading hours and its Kuwaiti listings for 0.11 percent, and only noon Food did better in either market. A Keeta discount that has stopped appearing is therefore almost never a listing that went down while nobody was looking. It is a promotion that the platform, an item edit or an unfinished job took off the shelf.

Does Keeta publish a promotions API for restaurants?

No. The restaurant integration documentation lists its full surface, Basic with four methods, Order with thirteen, Store with nine and Menu with twenty nine, and there is no promotion, discount, coupon or campaign endpoint among them. Source: api-docs.mykeeta.com.

The missing endpoint is the operational fact. A chain that integrates Keeta through a POS or middleware can push menus and manage store status programmatically, and cannot read back what promotions are live. There is no job object to poll, no error list to inspect, and no way to reconcile a campaign plan against the platform without opening branch pages. On every other major platform in the region an operator can at least ask the API what it thinks is running. On Keeta’s restaurant side that question has no address.

What is Keeta’s “Promotion Offline Notification” and what triggers it?

It is a webhook, event ID 7001, and Keeta describes it as being “sent by Keeta to notify the third-party system when an existing promotion is taken offline.” The reasons are named in the same document: “Product price changes, product removals, or promotion conflicts and overrides may cause an existing promotion to be taken offline.” The payload identifies where it happened, since “The vendorId field identifies the vendor associated with the offline promotion” and “The detail field contains SKU-level promotion offline details.”

The Promotion Offline Notification belongs to Keeta’s grocery documentation rather than its restaurant documentation, and we are not going to claim otherwise. What it establishes is Keeta’s model of a promotion, and that model is worth knowing on either side of the business: Keeta treats a promotion as something the platform can withdraw on its own when the underlying item changes. A price edit or a delisting is enough. Source: api-docs.mykeeta.com.

Why can only one Keeta promotion be active on an item at a time?

Because Keeta says so in the constraints on its promotion endpoint, verbatim: “Only one promotion can be active for the same SKU at any given time.” Alongside it sits the identity rule, “Keeta identifies a promotion by the combination of sku, conditions.startTime, and conditions.endTime”, and the note that “Only STRIKETHROUGH promotions are currently supported.”

For a chain running more than one campaign this is the mechanism behind the word “conflicts” in the offline notification. A second promotion touching an item that is already promoted does not stack and does not queue, it displaces. The item keeps a discount, but not necessarily the discount that was budgeted for it, and the campaign that lost the item is not told which item it lost. Keeta adds that “When conditions is omitted, the promotion becomes effective after creation and remains effective until it is updated or deactivated”, so an open ended promotion left in place from a previous season keeps occupying its items indefinitely and blocks whatever comes next. Removing items is done at the item level rather than by ending the campaign, since Keeta instructs partners to “Set discount[].active to false to remove the specified SKUs from the promotion.” The single method Keeta exposes for all of this is PUT /v1/promotion/chains/{chainId}, whose summary reads “Manage Promotion” and which Keeta describes as allowing a third party system “to create, update, or deactivate SKU-level promotions on the Keeta platform.”

How does a Keeta promotion fail for some branches and not others?

Through partial completion, which Keeta treats as an expected outcome rather than an error. Promotion changes are asynchronous, stated as “The request is processed asynchronously, and the processing result will be notified via webhook”, and the task itself is reported through a second webhook, event ID 8001, described as: “When Keeta’s platform receives an asynchronous request, it creates an internal task for processing.” Its jobStatus values are QUEUED, “The job has not started”, INPROGRESS, “The job is being processed”, COMPLETED, “Processing has finished”, and FAILED.

The important line is what a completed job contains: “When jobStatus = COMPLETED, the result will contain the task execution details, including vendors and SKUs that failed to create the promotion activity.” A completed task is therefore not a successful task. Some branches and some items can be listed as failures inside a job that finished normally, which is exactly the shape of the problem an operator experiences as a discount that reached eight branches out of ten. Source: api-docs.mykeeta.com.

What does Keeta not publish about promotion funding and approval?

Everything an operator would want. We searched both branches of Keeta’s public documentation for five things: a co funding split between the platform and the restaurant, a budget ceiling for a campaign, a minimum order value as a promotion parameter, an approval or moderation step, and any phrase equivalent to selected stores. None of those exist in Keeta’s public materials, and we are not going to invent them.

Those gaps leave the merchant portal as the only source of truth, and it sits behind a login. Keeta’s restaurant tooling is the Keeta Manager Portal at merchant.mykeeta.com, with the Keeta Partner app on both stores. For a chain, the practical consequence is that a promotion agreed commercially, configured in a portal and never confirmed anywhere else has no audit trail outside that portal. Keeta’s own separation between the branches of its documentation is a reasonable warning here: what is documented for grocery may or may not be how the restaurant side behaves, and the honest position is that Keeta has not said.

How does a Keeta restaurant operator check a campaign without an API?

The same way a customer would, and at the same cadence the campaign is supposed to run. Three properties of Keeta’s model make an outside check unusually valuable. Promotions can be withdrawn by the platform when an item changes. Only one promotion can hold an item at a time. A change that completes normally can still have left branches behind. None of the three produces an alert on the restaurant side, because there is no restaurant side promotions API to alert through.

Kitchain (kitchain.co) reads the discount rendered on each Keeta branch page every day and flags the branches where it stopped. On Keeta that is the only external record a chain can hold at all, because the platform exposes no promotion endpoint to a restaurant integration. One caution on research: the domain keeta.com belongs to an unrelated financial company. Keeta’s delivery business lives on mykeeta.com and keeta-global.com.

For the platform itself, its markets, its store states and how a Keeta listing goes dark, see our profile at kitchain.co/aggregators/keeta/.