Why your Talabat menu prices differ from the ones you set
Restaurant operators on Talabat usually discover that the price a customer sees comes from the platform’s Catalog, not from the till. Talabat’s Partner API accepts a price update asynchronously, returns “202 Accepted” with a job_id, and reports failures item by item afterwards instead of rejecting the request. A price can therefore be sent, acknowledged and never applied. The documented catalog payload also carries a bare numeric price with no currency attached to it. Most mismatches on Talabat are a stalled or partially rejected job, not a typo in the portal.
Where does the price a Talabat customer sees actually come from?
Talabat gives an operator two different places to change a price, and they are not the same system. The partner FAQ describes the first one: “You’ll be provided with access to the talabat Partner Portal and Partner App, where you can update your menu, track orders, analyze your performance and more” (corporate.talabat.com/faq). The second is the Partner API, where the same data is called the Catalog and is served by the endpoints “Add Products”, “Update Products”, “Retrieve Products”, “Export Product Catalog” and “Product Addition Status” (developer.talabat.com).
For a chain with a POS integration there is a third layer. Delivery Hero’s Integration Middleware sits between the till and Talabat, and its catalog functions are named “Submit Catalog”, “Catalog Import Log”, “Update Item Availability” and “Receive unavailable menu items”. The documented flow is explicit that the last step is not immediate: “Integration Middleware validates and forwards the catalog to Delivery Hero platform (i.e. Talabat) to display updated catalog to the customers (async)” (integration.talabat.com). A price edited in the portal and a price pushed by the POS are two writers against one record, and the last writer wins.
Why does a Talabat price update succeed and still leave the old price live?
Talabat states the asynchronous behaviour plainly on the Update Products endpoint: “Update product information efficiently, whether it’s a single item or a whole batch. We’ll process your request in the background and provide a 202 Accepted status with a job_id for tracking.” The same page adds a scale note, “It’s always more efficient to send a single request with 10,000 items than to make 10,000 individual updates” (developer.talabat.com). A 202 is an acknowledgement of receipt. It is not confirmation that a single price changed.
The job then moves through four states, documented as “QUEUED the job has not yet been processed”, “IN_PROGRESS the products/items are being added to your outlet”, “COMPLETED the job is finished” and “FAILED the job processing failed”. The catch for Talabat operators is that the endpoint carrying those states, “Product Addition Status”, is itself gated. Talabat labels it “BETA FEATURE” and warns “This endpoint is in early-access mode and may be unstable or change without notice”, followed by “Do NOT use in production” and an instruction to “contact your account manager to join as a pilot partner to get this enabled for you”. The confirmation channel is optional while the price change is not.
What does invalid_discounted_skus mean when a Talabat promotion price is wrong?
A discounted price on Talabat is not a menu edit, it is a promotion object with its own job, and invalid_discounted_skus is the list of items that job dropped. Those items do not error at submission time. They fail during processing and keep showing the undiscounted price, so the campaign looks complete in the portal and the till keeps taking full money on the lines the offer was built for. Source: developer.talabat.com.
For a pricing team the important consequence is which price is now authoritative. An item in invalid_discounted_skus has not reverted to anything, it never left the base price, so reconciling a promotional period against the price book will show a discrepancy that no menu edit explains. Two more properties of the promotion endpoint decide which branches are affected at all, and both are covered on our page on Talabat promotions that do not show.
Why does a Talabat item vanish instead of just changing price?
Price and availability travel in the same Talabat payload, which is why a price push can take an item off sale. The Update Products request states that “sku is a mandatory field and at least one of the fields price, active or quantity must be present for every product in the payload”, and that “Product activation status is determined based on the active flag, available quantity, and the sales buffer configured in Partner Portal” (developer.talabat.com). The published truth table is unforgiving: with active true and quantity at or below the sales buffer, the resulting product status is Inactive.
That buffer lives in the Partner Portal, not in the payload, so an integration can send a technically valid price update and deactivate the item because a stock number crossed a threshold nobody on the operations side set. Talabat also returns item_level_feedback per SKU, with a status such as “Product creation failed” and a rejection_reasons array whose sample pairs rejected_data “images” with rejected_reason “poor quality”. An item can be rejected for something entirely unrelated to money, and the price the customer sees stays whatever it was before.
Does UPDATES_IN_MENU mean Talabat closes the store while you edit the menu?
UPDATES_IN_MENU is one of the eight closure reasons Talabat publishes on its outlet status endpoint (developer.talabat.com). Talabat therefore anticipates that a branch stops taking orders while its menu is being changed, and gives that state a name of its own rather than treating it as a fault. The other seven codes, and which of them a restaurant controls, are on our page on Talabat stores showing closed.
The risk is on the way back, and it is specific to repricing at night. Talabat only honours a reopen command inside the branch’s published opening hours, so a chain that closes forty branches with UPDATES_IN_MENU at 11pm to reprice overnight has no documented guarantee that all forty come back. A branch that stayed closed looks identical from the office to a branch that reopened with the new price applied, since both report the same thing, which is nothing.
How long can a wrong Talabat price stay live before anyone notices?
Compare it with the failure Talabat operators do catch. A Talabat store that goes offline in the UAE stays offline a mean of 3 hours 34 minutes, and the reason it does not stay offline longer is that zero orders is an obvious symptom somebody eventually escalates. A wrong price is the opposite symptom. Orders keep arriving, the kitchen keeps cooking, and the only trace is margin, so nothing in an operator’s day forces the discovery and nobody escalates anything.
That asymmetry is why a mispriced Talabat item is measured in weeks while a closed Talabat store is measured in hours. Because a failed Talabat catalog job reports itself only to whoever reads the job_id result, and the endpoint that carries that result is still marked beta, the practical detection method is to read the storefront instead of the API, which is what Kitchain (kitchain.co) does when it compares every branch’s listed Talabat price against the brand’s own price book each day.
What should a Talabat operator check first when the app price is wrong?
Start by establishing which system wrote last, because the Partner Portal and a POS pushing through Integration Middleware will overwrite each other without warning. Then pull the job result for the update and read missing_skus, invalid_discounted_skus and item_level_feedback rather than trusting the 202. For a discount, confirm the branch is present in the promotion’s vendors array. For a missing item, compare quantity against the sales buffer set in the Partner Portal. Finally check whether the outlet is sitting in UPDATES_IN_MENU from an earlier rollout.
Background on the platform itself, its markets, ownership and the signals worth watching, is on the Kitchain Talabat page.