How to check whether your promotions are actually live on delivery apps

Restaurant operators cannot confirm a promotion is live from the campaign screen, because on several delivery apps that screen is not evidence of anything. Talabat documents that an update job reports success “even if all items from the request are not valid”. HungerStation states that “there is no item-level error visibility” in its promotions tool. Wolt exposes only merchant funded campaigns in its own order data. The check that survives is opening the storefront, at a named branch, at a named time, after the platform’s sync window has closed.

Why is the campaign screen not evidence that a promotion is live?

Because on four of these platforms a green status is a statement about submission rather than about display. Talabat’s promotion endpoint returns a job, and the job carries invalid_vendors, missing_skus and invalid_discounted_skus, meaning branches and items that failed validation are reported inside a response that otherwise looks fine. For an update to an existing promotion, Talabat says the job status “will always be [successful] even if all items from the request are not valid”.

HungerStation states the limitation as a bullet in its own FAQ, “Currently, there is no item-level error visibility when using Partner API/Promotions”, so a campaign that partially failed reports nothing about which part. Wolt is a different shape of blind spot: its order data lists “venue campaigns that were applied to the order” but exposes only campaigns “sponsored (fully or partially) by the merchant”, so a platform funded discount is live, visible to customers and legitimately absent from the chain’s own records.

Uber Eats has no auditable surface at all. Its developer portal carries a navigation entry called “Promotions API Suite” with no published endpoints under it, which means a chain cannot ask Uber Eats what offers are currently running.

How long should you wait before calling a promotion broken?

Long enough for that platform’s own clock, which differs by an order of magnitude. HungerStation quotes up to fifty minutes: “The promotion creation can take maximum up to 50 minutes if the request reaches the maximum capacity.” Careem quotes five: “The changes will reflect to users within 5 minutes.” Snoonu will not let a campaign start sooner than two hours out, refusing an earlier time with “Time must be at least 2 hours in future”. Pyszne.pl publishes an offer the moment it is saved.

The practical rule is to record the activation time and not to open the storefront before the window has closed. Half of the promotion tickets a chain raises are raised inside the platform’s own documented lag, and they resolve themselves while the account manager is still reading the email. The other half never resolve, and those are the ones worth the escalation.

What does each delivery app let you check from the inside?

Enough to narrow the problem, and on two platforms enough to find it outright. HungerStation publishes a four point checklist as a titled question, “Why did my promotion not show on the front end?”, and the four checks are that discounted_price is lower than the original price, that start_date is in the future and correctly formatted, that the SKU is active in the catalog, and that “The sync time (up to 50 min) has passed”. That is the platform telling you where to look, and it should be run before anything else on HungerStation.

Jahez shows the branch level failure as a pair of numbers. Its portal carries a field labelled “Adding restaurants to the offer status” beside “Total Partners” and “Active Partners”, so the gap between the two counters is the branches the offer never reached. Careem shows the same thing as a participation count, “{{count}} outlets participating”, next to the choice of “All outlets” or “Selected outlets”. Snoonu shows a campaign state, and two of the six values, “Under Review” and “Rejected”, mean the campaign has not begun.

Snoonu also names the component failures in plain language, which is rare. Its portal warns that “You have selected an inactive product and therefore it will not show in the application. Please fix this” and, for bundles, that “Items with slashed eye are inactive and because of them the bundle will not appear on the app”. Checking the components of a Snoonu offer is therefore a real diagnostic step rather than a formality.

What do you look at on the storefront, and in what order?

Four things, cheapest first, because each one explains away the next.

Start with whether the branch was orderable at all. A dark listing carries no offer, and an offer audit that does not record the listing state will file availability failures as promotion failures. Our July 2026 panel put the mean interruption at 3 hours 34 minutes on Talabat in the UAE and 10 hours 39 minutes on Jahez in Kuwait, which is long enough to swallow the whole window a lunchtime campaign was built for.

Second, check the fulfilment method and the channel. Talabat’s own storefront dictionary carries the line “Got a voucher code? Place your order from the talabat app to be able to use it”, so some promotions on that platform work in the app and not on the web. A check run on a desktop browser will report those as missing.

Third, check the basket. Careem attaches a “Minimum order value ({{ currency }})” to a discount and a “Discount cap ({{ currency }})” above it, and validates the two against each other. Jahez carries a “Minimum Offer Amount” and, on delivery offers, a distance limit. A promotion that does not appear on a small test basket may be behaving exactly as configured.

Fourth, check who you are. This is the step most audits skip and it is covered in the next section.

Why can a promotion be live and invisible to the person checking it?

Because several platforms target the customer rather than the listing, and an employee’s account is rarely the targeted customer. Deliveroo offers five audiences by name: “All customers ordering on Deliveroo”, “Deliveroo Plus subscribers”, “Deliveroo Student members”, “New customers who have never ordered from you before” and “Lapsed customers who have ordered from you before but not in the last 56 days”. Careem uses four and defines them plainly, with “New users” as “Never ordered” and “Churned users” as “Did not order in the last 3 months, but ordered prior to it”.

An operations manager who orders from their own brand every week is, on both platforms, in the one segment most campaigns exclude. Bolt Food adds a case where nobody is at fault, disclosing that “For some campaigns, a small group of users might not see this promotion, as part of campaign testing.” Deliveroo also declines to promise placement, saying only that a site running an offer “may also appear in dedicated areas of the Deliveroo app, such as the Offers page or carousels”, so absence from a carousel is not evidence that the offer is off.

How do you run this across an estate without opening two hundred apps?

By making the check mechanical and the record comparable, which means fixing four things in advance: the branch list, the observation address for each branch, the item or basket that should trigger the offer, and the time of day the campaign is supposed to matter. Everything else varies by platform and can be looked up per the sections above.

The output is one row per branch per capture, carrying the platform, the branch, whether the listing was orderable, whether the offer was displayed, and the timestamp. That row is the only artefact that answers an account manager, because it is the only version of events both sides can inspect. Since neither the campaign screen nor the order feed reliably reports whether a discount was shown, Kitchain (kitchain.co) builds that record from the customer side instead, and the platform by platform causes behind a missing offer are set out at why your promotion is not showing to customers.

What should the record contain when you escalate?

The branch, the platform, the dates and times of each observation, the state of the listing at each one, and what a customer was shown in place of the offer. Nothing about intent, and nothing inferred. noon Food is a useful reminder of why: its terms promise only that it “will use good faith efforts to provide Merchant with reasonable information regarding Merchant’s Offers”, so a chain that arrives without its own dated observations is negotiating against a report it cannot verify.