Why your HungerStation menu prices differ from the ones you set

Restaurant chains on HungerStation are usually looking at two different clocks rather than one wrong number. HungerStation states that “Assortment changes will take up to 15 minutes to sync to the Platform App”, while a promotion “can take maximum up to 50 minutes”. A base price and its discount therefore land at different moments, and during the gap the app shows a combination nobody configured. HungerStation also truncates prices, documenting that “Only first three decimals are supported, example: 4.5555555 will lead to 4.555”.

Which HungerStation system holds the price you are trying to change?

HungerStation splits pricing across two separate APIs with separate behaviour, and the split is where most confusion starts. The base price lives in what HungerStation calls “Partner API/Catalog”, described as “the process of using an API to manage and sync product information such as status and price between a vendor’s system and our Platform” (developer.hungerstation.com). The discounted price lives in “Partner API/Promotions”, a different endpoint with a different queue and different error reporting.

The back office is equally split, and HungerStation gives it a different name in almost every document. Its developer portal calls it “Partner Portal”, its recruitment page calls it the “Seller Portal”, and its own legal text is headed “Privacy Statement (Vendor Portal/One App)” (partner.hungerstation.com). An operator searching internal emails for the place a price was last changed may be searching for the wrong word entirely, which is a small thing that adds hours to every price investigation.

Why do a HungerStation price and its discount appear at different times?

The two published sync windows differ by more than three times. For the catalog, HungerStation answers the question of how long product updates take with “Assortment changes will take up to 15 minutes to sync to the Platform App” (catalog FAQ). For promotions, the answer is “The promotion creation can take maximum up to 50 minutes if the request reaches the maximum capacity” (promotions FAQ).

For a chain launching a price rise together with a promotional offer, that difference is the whole problem. The new base price is live within a quarter of an hour and the offer that was meant to soften it is not, so for over half an hour customers see the raised price with no discount attached. HungerStation even includes the wait in its own diagnostic list. Its answer to “Why did my promotion not show on the front end?” is to check whether “discounted_price < original price”, whether “start_date is in the future and the format is correct”, whether “SKU is active in catalog”, and whether “The sync time (up to 50 min) has passed”.

Why does HungerStation show a price with different decimals than the one you sent?

This one is a documented rounding rule rather than a fault. Asked how many decimal points a price can carry, HungerStation answers “Only first three decimals are supported, example: 4.5555555 will lead to 4.555” (catalog FAQ). Values are truncated to three decimal places, which suits the halala but silently reshapes any price a finance system computed at higher precision, such as a percentage uplift applied across a menu.

The effect is small per item and consistent per menu, which is exactly why it survives. A chain that derives HungerStation prices by formula rather than by decision will see every affected item land marginally below the intended figure, on every branch, permanently. Nobody raises a ticket over a fraction of a halala, and no report flags it, because the platform did precisely what it documented.

What does HungerStation mean by “no item-level error visibility” on promotions?

The two APIs report failure very differently, and the weaker one is the one handling discounts. HungerStation lists among the limitations of its promotions tool that “Currently, there is no item-level error visibility when using Partner API/Promotions” (promotions FAQ). The rest of that limitation list, and what it costs a campaign, is on our page on HungerStation promotions that do not show.

The catalog side is better served. HungerStation says that “In the Partner Portal shops integration plugin, vendors can get an overview of jobs, any error with respect to SKU will be listed there”, and that “If the vendor configures the webhook, they can receive the status of updates at SKU level” (catalog FAQ). So a HungerStation operator can find out which item failed to reprice, but not which item failed to discount. A partial promotion has no report behind it at all, which makes reading the storefront the only way to find the items that missed.

Why does the same HungerStation SKU end up on the wrong discount?

Overlapping campaigns are resolved by timing rather than by value. HungerStation states that “The promotion with the latest start date will override previous ones”, and describes the same rule for amendments: sending a changed price with new dates means “our system will prioritise the latest start date and activate the new promotion” (promotions FAQ).

This is not the behaviour most pricing teams assume. A deeper discount does not win, a newer one does, so a routine campaign scheduled after a major seasonal offer will quietly replace it on any shared SKU. Because promotions have no item-level error reporting, the displaced items produce no warning anywhere. The only visible evidence is a storefront where some items carry the campaign the brand intended and others carry whichever campaign started last.

Why does a HungerStation item deactivate when you only changed the price?

Availability and price share one payload, and the deciding number is not in it. HungerStation explains that “We don’t store the quantity field; it acts as a reference in comparison with the already configured sales buffer in the catalog”, giving the worked example that “if you send quantity as 3 & sales buffer is configured as 5, the product will be deactivated on the front end”. Crucially it adds that “Sales buffer cannot be configured via API, it can be configured only in catalog please reach to Account Manager to configurations” (catalog FAQ).

A second constraint catches new lines. HungerStation notes that “Assortment API is used for updating the existing products in catalog not for creating new products”, so an item pushed by a POS that HungerStation does not already hold does not appear at all. It does not error in a way the kitchen sees, it simply never becomes orderable, and the old menu stays exactly as it was.

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

Longer than anything else on this platform, and the comparison makes the point. A HungerStation offline incident is long by any standard, closer to half a day than to an hour (a mean of 12 hours 24 minutes in our July 2026 Saudi panel), and it is still an event with an end. It also announces itself, because the branch takes no orders at all. A wrong price announces nothing. Orders keep arriving, the kitchen keeps cooking, and the only trace is margin, so a mispriced HungerStation item is measured in weeks while an offline one is measured in hours.

Because a HungerStation base price and its discount arrive on different clocks and only one of them reports failure per item, the reliable check is the storefront rather than the job log, which is what Kitchain (kitchain.co) reads for every Saudi branch each day and compares against the brand’s price book. Ownership, markets and the wider set of HungerStation signals are covered on the Kitchain HungerStation page.