Why your Keeta menu prices differ from the ones you set

Restaurant chains on Keeta are usually looking at one of three prices rather than at a wrong one. Keeta stores a separate delivery, pickup and dine-in price on every item, documented as price, pickPrice and canteenPrice. Its menu endpoint performs a full replacement, treating as a deletion “All existing entities with openItemCode values not present in the request”. Keeta also warns that “A successful response only confirms successful submission of the synchronization task”, because individual items can still fail validation after that response.

Which of the three Keeta prices are you actually looking at?

Keeta is unusual in modelling fulfilment channels as separate price fields on the same item rather than as one price with adjustments. The Menu Management API defines SKU.price as “Delivery price (supports 3 decimal places, e.g. “12.33”)”, SKU.pickPrice as “Pickup price (supports 3 decimal places)” and SKU.canteenPrice as “Dine-in price (supports 3 decimal places)” (Keeta Menu Management API). A fourth field, SKU.currency, is described as defaulting “to merchant’s currency if empty”.

An integration that maps a single POS price onto price alone leaves pickPrice and canteenPrice holding whatever they held before, potentially since onboarding. The customer switching from delivery to pickup then sees a price the brand stopped using months ago, and every internal check passes, because the delivery price everyone looks at is correct. Modifier prices add a second trap: ChoiceGroupSku.price is documented as supporting only “2 decimal places” against the item’s three, so an item and its options do not even round the same way.

Why does a Keeta menu sync delete items you did not mention?

Because Keeta’s sync is a replacement rather than a patch. The Menu Synchronization endpoint states that “The system performs full-menu updates based on the provided data, implementing entity matching through the openItemCode field”, and spells out three outcomes: “Update: When matching openItemCode values exist in the store’s current menu”, “Addition: When no matching openItemCode values are found”, and “Deletion: All existing entities with openItemCode values not present in the request” (Keeta Menu Management API).

The deletion rule is the one that surprises operators. A partial export intended to change five prices does not change five prices, it deletes everything else on the menu. There is no confirmation step and no diff to review, because from Keeta’s side the request was complete and valid. The identifier doing the matching is openItemCode. Any change in how a POS generates that code, whether a prefix, a branch suffix or a migration, converts an update into a deletion plus a re-creation of the whole menu, at whatever prices the new payload carried.

Why does a successful Keeta menu upload still leave items unchanged?

Keeta separates acceptance from application, and says so directly. Under execution semantics it states that “A successful response only confirms successful submission of the synchronization task. Certain items may still fail during processing due to validation rules, requiring manual verification and resubmission by the caller” (Keeta Menu Management API). The burden of verification and resubmission is placed explicitly on the caller.

The batch status endpoint behaves the same way with one sharp edge. Keeta notes that “The interface supports partial synchronization success and partial synchronization failure. However, if there is a parameter format error, all will fail.” So a menu push has two very different failure modes: a formatting mistake stops everything and is obvious, while a validation failure on individual items lets the rest through and is invisible. The second is the one that produces a storefront where most prices moved and a handful did not.

Why does changing a Keeta price switch off the promotion on it?

Keeta documents the behaviour rather than treating it as a defect, and it catches chains during price rises. Keeta names the trigger in the specification for the webhook it sends when a promotion is withdrawn: “Product price changes, product removals, or promotion conflicts and overrides may cause an existing promotion to be taken offline” (Keeta webhook specification). The rest of that webhook, and what it says about how Keeta treats a promotion, sits on why your Keeta promotion is not showing.

A base price change therefore takes the discount attached to that item down with it. An operator who raises a list price expecting the existing offer to keep applying gets the raised price at full rate instead, which is a larger jump than anyone approved. Keeta reinforces the coupling from the other direction, noting on its batch update endpoint that keeping the identifier stable “is very important for Promotion activities, which are based on Spu.id and Sku.id”. Promotions are bound to identifiers, not to items as a person understands them.

What happens if a Keeta item is updated without its Sku.id?

Keeta creates a second one. The batch update endpoint states that “As for Sku, if the Sku.id is filled, please make sure the Sku.id is belongs to this Spu. If Sku.id is not filled, we will treat it as a new one” (Keeta Menu Management API). An update that omits the identifier is silently promoted into a creation, and the storefront ends up carrying the same dish twice at two different prices.

Name based matching carries a related risk that Keeta describes candidly. Where a modifier is not explicitly bound, automatic binding happens on matching names, and Keeta warns that “If multiple SPUs share identical names, the system randomly selects one for binding, which may lead to unintended synchronization”. A chain with a “Regular” or “Large” appearing across several items has no guarantee which one a modifier attaches to, and the resulting price on the storefront is not reproducible from the payload alone.

How does Keeta hide a category you never touched?

Category visibility on Keeta is derived rather than set. The synchronization rules state that “Categories become hidden when all contained products are delisted, and are repositioned when products become temporarily unavailable”, and the status endpoint repeats it more bluntly: “If there is no available product in a ShopCategory, the ShopCategory will disapear at user APP” (Keeta Menu Management API). The spelling is Keeta’s own.

For price work this means a single failed batch can remove a whole section of the menu. If the items in one category all fail validation on a sync, the category stops appearing, and nothing in the account reports a missing category because no category was changed. The operator sees a menu that is shorter than it should be and prices that look correct on everything still visible.

How long can a wrong Keeta price stay live before anyone notices?

Longer than the platform’s downtime figures would suggest, because the two things are watched by different people. Kitchain (kitchain.co) measured Keeta at 1.02 percent of trading time lost in the UAE in July 2026 and 0.11 percent in Kuwait, among the lowest figures we record anywhere. Store status gets that kind of result because a Keeta suspension never clears itself and operators have learned to watch for it. Nobody watches a pickPrice with the same attention, and no equivalent alarm exists for one.

A Keeta menu push reports submission rather than outcome, and Keeta itself expects the caller to verify and resubmit. The reliable check is therefore the customer-facing menu rather than the API response. Kitchain (kitchain.co) reads that menu branch by branch each day and compares it against the brand’s price book. Ownership, markets and the wider set of Keeta signals are covered on the Kitchain Keeta page.