Why your HungerStation promotion is not showing to customers

HungerStation answers this question itself, and restaurant operators should start with its answer rather than a theory. Its developer FAQ contains a question titled “Why did my promotion not show on the front end?” and gives four checks: 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”. Fifty minutes is long enough for a launch to look broken before it has finished.

The fifty minutes collide badly with how this platform goes offline. HungerStation outages are long (a mean of 12 hours 24 minutes across our Saudi panel in July 2026) and they start at night, with 81 percent of them beginning between 22:00 and 02:00. A campaign activated in the evening therefore has a real chance of finishing its sync into a storefront that is no longer there, and every check run the next morning reports a promotion that does not show. Launch in daylight and the ambiguity disappears.

What is HungerStation’s own checklist for a promotion that did not show?

Four items, published verbatim in the Promotions API FAQ. “Check if: discounted_price < original price, start_date is in the future and the format is correct, SKU is active in catalog, The sync time (up to 50 min) has passed”. Each of the four fails silently, and each fails for a different reason.

A discounted_price that is not lower than the original is the commonest of them in practice, because it happens without anybody editing the promotion. A price rise pushed through a menu sync can lift the base price above the discounted one, at which point the promotion is arithmetically void while still being present and active in the system. An inactive SKU behaves the same way: the promotion exists, the item it points at does not appear, and the campaign quietly covers fewer items than the plan says. Source: developer.hungerstation.com.

How long does a HungerStation promotion take to appear on the front end?

Up to fifty minutes, and HungerStation states it as a capacity dependent maximum rather than an average: “The promotion creation can take maximum up to 50 minutes if the request reaches the maximum capacity”. That is the longest publication window we found among the platforms operating in the Gulf, and it changes how a launch should be run.

It also changes how a launch should be checked. Fifty minutes after a Friday evening activation is a materially different point in the trading day, and a chain that verifies coverage immediately after pressing the button will always see gaps that resolve themselves. The corollary matters more: a gap still present an hour later is real, and no further waiting will fix it. HungerStation names the two mechanics available through the tool as strikethrough discounts, covering “percentage off, absolute value off, final price”, and same item bundle discounts, covering “percentage off, absolute value off, free item”.

Why does one HungerStation promotion override another on the same SKU?

Because the tie break is the start date, not the size of the discount. HungerStation answers the overlap question directly: “The promotion that has a later start_time will be visible after it overlaps the first promotion”, and states the general rule as “The promotion with the latest start date will override previous ones.”

For a chain that runs a national campaign and a local one, this is a live risk rather than an edge case. A branch level offer created after a national offer will take precedence over it on any shared SKU, regardless of which is more generous to the customer or which was more expensive to buy. Nothing warns either campaign owner, and the outcome depends on the order in which two teams happened to press save. Source: developer.hungerstation.com.

Why can a HungerStation promotion reach some branches and not others?

Two documented reasons, and they compound. The first is scope. HungerStation supports both a branch list and a whole chain wildcard: “Can I create the same promotion for multiple vendors? Yes. It can be done in ‘vendors’ parameter (can be platform id or partner’s external id mapped in Partner Portal). If vendors = [*] promotion will be applied to all vendors associated with the chain.” A promotion built with an explicit list rather than the wildcard is a snapshot of the estate on the day it was written.

The second is a structural limit on how requests can be composed, and it is stated plainly among the tool’s constraints: “It is not possible to create promotions for different skus and different vendors in a single request”. A chain whose branches carry different menus therefore needs several separate calls to cover one campaign, and a campaign that needs six calls can complete five of them. There is no single object representing the campaign as a whole, so nothing exists to report that the sixth is missing.

Why does HungerStation not tell you which item failed?

Because it says it does not. The list of documented limitations includes the line “Currently, there is no item-level error visibility when using Partner API/Promotions”, alongside “Promotions created via API must be modified via API” and “To modify/delete a promo, the same body request is required”. A campaign covering hundreds of SKUs can therefore succeed at the request level and fail for an unknown subset of items, with no way to find out which subset from the response.

That is the gap this symptom lives in. HungerStation gives an operator a checklist for diagnosing one promotion by hand, and no machine readable way to run that checklist across an estate. Changing the dates on a live promotion is not possible either, it has to be deactivated with "active": false and recreated, which starts the fifty minute clock again. Updates are keyed on SKU only, since “Can I use SKU or Barcode for updates? No, only SKU is supported”. The stated ceiling is generous, “Partner can create up to 2 M promotions in one request (skus*vendors)”, which makes the absence of item level errors more consequential rather than less.

Who grants access to the Shops Promotions plugin in the HungerStation Partner Portal?

An account manager, not the operator. HungerStation states that “You can access the Shops Integrations plugin in Partner Portal, you will be given access by your account manager or during registration with us”, and the same applies to the identifiers a campaign needs: “Please reach out to your Account Manager to get the Vendor ID.” Where partners view what is live is also named: “We offer Shops Promotions plugins accessible through the store’s Partner Portal account that will allow you to check the current promotions.”

We looked for a published co funding split between HungerStation and the restaurant, a budget ceiling in money, and a moderation step for a promotion, across the whole developer portal and the Delivery Hero developer documentation. We did not find any of the three, and we are not going to guess at them. The marketing framing in the HungerStation partner app stays at the level of “Offer attractive discounts to thousands of Hungerstation’s users. Join campaigns to increase your visibility and acquire new customers.”

How should a Saudi chain verify a HungerStation campaign across its estate?

From the customer side, because that is the only place where a fifty minute sync, a silently overriding start date and an unreported item level failure all become one visible fact. The Partner Portal shows what was requested. The app shows what customers get. Kitchain (kitchain.co) records the discounts rendered on each HungerStation branch page daily and flags branches where a promotion that ran yesterday is absent today, which is the specific case HungerStation’s own tooling states it cannot report on.

For the platform itself, its ownership, its markets and how a HungerStation storefront goes offline, see our profile at kitchain.co/aggregators/hungerstation/.