Why your Talabat promotion is not showing to customers

A Talabat promotion is not a switch you flip, it is a background job, and restaurant chains lose discounts in the gap between the two. Talabat’s Partner API creates promotions through POST /v2/chains/{chain_id}/promotion and returns a job that has to be polled separately. The job response carries invalid_vendors, missing_skus and invalid_discounted_skus, so branches and items that fail validation drop out quietly. Talabat’s own documentation adds that when you update an existing promotion, the job status will always be COMPLETED even if all items from the request are not valid.

There is a second way a Talabat promotion can be genuinely absent while nothing is wrong with it. A dark storefront carries no offer, and Talabat interruptions run longer than those of any other platform in our UAE panel, long enough to cover the whole window in which a lunchtime campaign was supposed to matter. Our July 2026 panel measured the mean at 3 hours 34 minutes. Anyone auditing coverage branch by branch has to record whether the branch was open at that moment, or half the misses will be attributed to the wrong cause.

What does the vendors field control in a Talabat promotion?

Everything about which branches see the offer. Talabat’s Partner API specification describes vendors as a “Set of vendor IDs relevant to the promotion” and adds the rule that matters most to a multi branch operator: “If vendors = [“*”] promotion will be applied to all vendors associated with the chain”. A promotion is therefore chain scoped only when someone explicitly writes the wildcard. Any other value is a hand built list, and a branch that opened after the campaign was created, or that was mapped under a new vendor ID, is simply not in that list. Nothing in the customer app signals the omission. Source: developer.talabat.com/api-specifications.

This is the single most common reason a Talabat discount appears at nine branches out of eleven. The list is a snapshot of the estate on the day the campaign was built, and estates change faster than campaigns do. Chains that run one promotion per city, or that split promotions by menu variant, end up maintaining several vendor lists at once, and the branch that falls through the cracks is usually the newest one. Checking means comparing the intended branch list against what customers can actually see, branch by branch.

Why does a Talabat promotion job report success when branches were dropped?

Because the job status and the promotion outcome are two different things. Talabat describes the job endpoint GET /v2/chains/{chain_id}/promotion/jobs/{job_id} as a way to “Monitor the status and outcome of your promotion updates to ensure they are applied correctly”, and the response “provides additional details about the job processing, such as any SKUs or vendors that will not be included in the promotion due to an error once the processing is complete”. So the failures are reported, but inside a field, not as a failed job.

For updates Talabat is explicit that the top line is not diagnostic. Its documentation states that “for update cases (promotion already exists for a specific time interval for a given set of vendors), once processed, the job status will always be COMPLETED even if all items from the request are not valid.” A POS integration or a menu tool that only checks for COMPLETED, which is the normal thing to build, will report a clean run for a campaign that reached nobody. Source: developer.talabat.com/api-specifications.

How long does a Talabat promotion take to reach the customer app?

Talabat does not publish a number. It publishes an architecture, and the architecture is asynchronous by design: the Promotions endpoints exist to “Create or update promotions in the background for efficient processing and resource management”. That wording is the reason a campaign can look finished in the portal and not yet be finished on the platform. There is no documented approval or moderation step for self served Talabat promotions in the public specification, and no published service level for how long processing takes, so the only honest answer for an operator is that the job has to be polled rather than assumed.

Two promotion types are documented in the type enum, STRIKETHROUGH and SAME_ITEM_BUNDLE, with the note that “The Same Item Bundle promotion type is currently under active development and will be available soon.” A campaign built around a bundle mechanic can therefore fail for a reason that has nothing to do with the estate. Alongside them sit promotion.Limits, described as a “Set of available limitations on promotion or order level”, and promotion.Condition, a “Flexible setup of the conditions”, which is where minimum basket rules live. A customer under the minimum sees the menu without the discount and reports it as a missing promotion.

Which Talabat promotions only work inside the talabat app and not on the website?

Voucher codes. The localisation dictionary that ships with the Talabat customer storefront contains the string voucherMessage, rendered to customers as “Got a voucher code? Place your order from the talabat app to be able to use it.” Anyone testing a campaign in a desktop browser is testing a surface that cannot accept the code at all. The same dictionary shows how discounts are labelled on the customer side, which is what an operator should actually be looking for when auditing: labelDiscount is “Discounts”, labelDeals is “Special Deals”, promotionsTab is “Promotions”, offerFromTalabat is “Offer from Talabat”, binOfferText is “Discounts available for Bank Cards” and gemExpired is “Oops! Your offer has expired”. Source: talabat.com/uae/restaurants.

The label offerFromTalabat is worth its own line in any audit. It marks a discount that the platform is funding, sitting in the same carousel as the discount the restaurant is funding, and a customer or an area manager glancing at the app cannot tell the two apart. A branch can look well covered in promotions while none of the visible offers is the one the brand paid for.

What does the reason field say about who is funding a Talabat promotion?

The reason field is the closest thing to a funding label the public Talabat specification contains, and Talabat states it is not shown to customers. The enum carries six values, COMPETITIVENESS, NMR, TRADING, EXPIRING_SOON, OVERSTOCK and DELISTING, each with its own definition. NMR is defined as “Suppliers paying for banners to gain visibility for their products (with or without discount)”, and TRADING as “promotions to drive traffic/volume and achieve sales targets (more tactical, eg flash sales, basket discounts)”. Source: developer.talabat.com/api-specifications.

What Talabat does not publish anywhere in its partner materials is a co funding percentage, a cash budget ceiling for a campaign, or a moderation timeline. We looked for all three and found none, so an operator asking who absorbs the discount has to get that answer from a commercial agreement rather than from documentation. On the merchant side the pitch stays deliberately general: the talabat partner app in Google Play promises “Grow your business with marketing solutions” and invites partners to “Join campaigns to increase your visibility and acquire new customers”.

How can a chain tell whether a Talabat promotion is actually live at every branch?

By looking at the storefront the customer looks at, because that is the only surface where invalid_vendors and a silently successful update job become visible. The vendor portal shows intent, the customer app shows outcome, and on Talabat those two can disagree for weeks without anything failing loudly. Kitchain (kitchain.co) reads the promotion actually rendered on each Talabat branch page every day and raises an alert when a discount that was live yesterday is gone today, which is precisely the failure mode Talabat’s own job semantics are designed to tolerate rather than report.

For the platform itself, its markets, its portal names and what else changes underneath a listing, see our full profile at kitchain.co/aggregators/talabat/.