How to get HungerStation to put your restaurant back online
Restaurant chains on HungerStation return a vendor to trading by writing a status rather than by asking anyone, and the write can be refused for two separate reasons that have nothing to do with the kitchen. The status is documented as OPEN and defined as “open closed vendor if it’s within opening hours according to schedule”, so the schedule has a veto. Above that sits a middleware flag that decides whether the vendor is allowed to change its own availability at all. HungerStation publishes no rule under which a closed vendor reopens by itself.
Which HungerStation status do you write to bring a vendor back?
OPEN, sent to the outlet status endpoint, and it is one of a set of four the platform accepts. The published enum is “CLOSED_TODAY” “CLOSED_UNTIL” “OPEN” “CHECKIN”, with CLOSED_TODAY meaning “vendor will be closed till the end of the day”, CLOSED_UNTIL meaning “vendor will be closed till the date specified in closed_until field”, and OPEN meaning “open closed vendor if it’s within opening hours according to schedule”. Source: developer.hungerstation.com.
The call goes to the production host https://hungerstation.partner.deliveryhero.io, at PUT /v2/chains/{chain_id}/vendors/{vendor_id}/status, and the same path read back with a GET returns the current state. Source: developer.hungerstation.com.
For a brand without an integration the same job is done in the portal or in the merchant application, which HungerStation describes in its own store listing with the line “Easily adjust your store’s opening times”. Note which half of the problem that sentence solves. Adjusting hours is the schedule layer. Changing today’s status is the availability layer, and on this platform the second one answers to the first.
Why an OPEN call is refused, and what to change instead
Because the schedule is checked before the status is applied. The definition of OPEN carries the condition inside it, “if it’s within opening hours according to schedule”, which means a vendor whose weekly hours say it is shut cannot be opened by any status write. The fault presents as an unresponsive control and is a rule.
That makes the schedule the first thing to inspect in any HungerStation recovery, not the last. A vendor that trades until midnight but whose hours were entered as ending at eleven will refuse to reopen for the final hour of every single shift, and each of those refusals will be logged internally as a platform problem.
The second condition is the closure type itself. A vendor read back as CLOSED_UNTIL carries a closed_until timestamp, described as “Date and time till the vendor will stay closed in UTC (ISO 8601 format, UTC timezone)”. Reading that field before acting tells an operator whether they are looking at a closure with an end already attached or at one that will sit there until it is written over.
What HungerStation does not publish anywhere is a rule that a closed vendor comes back automatically. We checked the developer portal and the Delivery Hero material and there is no statement of automatic reopening. The end of day semantics of CLOSED_TODAY are not the same thing as a published promise, and we are not going to present them as one.
Check the changeable flag before you try, because the right can be withdrawn
This is the part most operators do not know exists. In the Delivery Hero Integration Middleware that sits under HungerStation, a vendor’s availability endpoint returns a changeable property, and the documentation is explicit about the order of operations: “It should first be checked which kind of availability changes are allowed by making a GET request to this endpoint and verifying that the changeable property is true otherwise the request will be unsuccessful.” Source: Delivery Hero Integration Middleware specification.
The examples in that specification contain both changeable: false and changeable: true, which means the right to set your own availability is a permission a platform can remove. A vendor in that condition will fail every reopen attempt, return no useful error to the person pressing, and look from the shop floor exactly like a broken integration.
The same response also carries the permitted closure lengths and reasons for that particular vendor, with closingMinutes shown in examples as 30, 60, 120, 240 and 720 minutes and a closingReasons list scoped to the platform. Those sets differ from platform to platform inside Delivery Hero, so a group running several of its brands should read the values back per vendor rather than assuming one list applies everywhere.
How a HungerStation check-in acknowledgement differs from an open
They look similar and they are not the same action. CHECKIN is described as a status you send “to acknowledge required check in”, with the qualifier that “This status works only if checking feature has been enabled for the vendor”. The feature exists to confirm a scheduled opening in advance, described as letting a partner “confirm the upcoming opening of your shop up to 30 minutes before its scheduled opening hours”.
The failure mode is stated without hedging: “If the you fail to acknowledge, the shop will remain closed even if it is scheduled to be open.” That is a shop that is not closed by any decision, has no closure reason attached, and will be invisible to any report that looks for closures.
Usefully, HungerStation also publishes the escape route in the same paragraph: “However, the shop can still be opened by calling the API with a “OPEN” status.” So a missed check-in does not require a support request. It requires somebody to notice and to send the ordinary open, which is exactly the kind of small action that never happens without an external alert.
Check-in is off unless somebody asked for it, since HungerStation states that “By default, this feature is disabled and does not require a check-in status to be sent” and that activation goes through an account manager. A brand that does not know whether it is enabled cannot know whether an unopened morning was a missed acknowledgement or something else.
What happens when Delivery Hero disables the integration rather than the store
The recovery moves out of the restaurant’s hands entirely, and the published wording is specific about who ends it. Delivery Hero states: “The integration might get disabled by Delivery Hero whenever there is a technical issue with the plugin and provided contact is not responding. The integration will be re-activated once the issue is fixed by plugin maintainer.” Source: developers.deliveryhero.com.
Two details in that sentence decide how long the outage runs. The trigger is partly a contact who is not responding, which means the person listed against the integration is part of the recovery path whether or not they know it. And reactivation is conditioned on the plugin maintainer fixing the issue, which is usually the point of sale vendor rather than the restaurant, so the brand is waiting on a third party with its own queue.
A harder version follows in the same document: “Some features of an integration or even the whole integration might get disabled whenever certain article of the implementation contract ain’t fulfilled.” That is a contractual suspension of the integration with no published notice period and no published route back beyond fulfilling the article, and there is nothing an operator can press to shorten it.
Who grants the access a HungerStation reopen depends on?
An account manager, and HungerStation says so repeatedly rather than once. Access to the portal plugins is described as issued rather than self service: “You can access the Shops Integrations plugin in Partner Portal, you will be given access by your account manager or during registration with us.” The vendor identifier is the same, with the instruction “Please reach out to your Account Manager to get the Vendor ID.” Activation of the check-in flow is also routed there.
That produces a practical dependency worth resolving before an incident. A brand that does not hold its own vendor identifiers, does not know who its account manager is, and has never confirmed which staff accounts can reach the portal has a recovery time set by a chain of introductions rather than by an API call.
The measured cost of getting this wrong in Saudi Arabia is large. Across our panel HungerStation listings are unavailable for 2.88 percent of trading time with a mean incident of 12 hours 24 minutes, or 0.77 percent and 5 hours once permanently dead listings are excluded. Incidents of that length are not caused by a slow reopen. On a platform where the reopen is a single call that returns in seconds, every hour of a twelve hour incident is an hour before the call was attempted. That is the part a reopen procedure cannot fix by being better written, and it is the part Kitchain (kitchain.co) closes by flagging the HungerStation storefront the moment it stops accepting orders.