Does HungerStation tell you when your restaurant goes offline?
Restaurant chains on HungerStation have one documented contact mechanism, and it exists to protect the platform rather than the branch. Delivery Hero, which owns HungerStation, writes that an integration “might get disabled by Delivery Hero whenever there is a technical issue with the plugin and provided contact is not responding”. That single sentence contains the whole notification model. There is a nominated contact, somebody chases them, and the consequence of silence is disconnection. Nothing in the published material describes a message sent to a restaurant when its own listing stops trading.
Who does Delivery Hero contact when a HungerStation integration breaks?
Whoever the integration named, and the outcome of failing to answer is stated in the same paragraph. The full text reads: “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.” Delivery Hero then goes further: “Some features of an integration or even the whole integration might get disabled whenever certain article of the implementation contract ain’t fulfilled.” Source: developers.deliveryhero.com.
The person being contacted there is a plugin maintainer, which in most chains is a software vendor rather than an operations manager. So the one documented human channel runs from Delivery Hero to a technical supplier, and the branch that has stopped receiving orders is downstream of a conversation it is not part of.
There is also no stated timescale. The provided contact is chased, the integration is disabled at some point, and it comes back once somebody fixes the plugin. A restaurant reading that sequence cannot work out how long it would be dark, because none of the three steps carries a published duration.
Can HungerStation take away your right to change your own status?
Yes, and you find out by asking rather than by being told. The Delivery Hero integration middleware exposes a vendor availability endpoint and instructs callers to check permission first: “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: integration-middleware.stg.restaurant-partners.com.
A changeable property that can be false means the right to reopen your own listing is a permission held elsewhere, and its state is discoverable only by making a request. Nothing announces the moment it flips. An operator who assumes they can always reopen a branch will discover otherwise at the least convenient point in the week.
The same endpoint is gated at the account level too, with the documentation noting that the feature has to be switched on: “Please contact your point of contact on Ops side to enable this feature for your integration.” Two separate human approvals therefore sit between a chain and the ability to control its own availability programmatically.
Which direction does the HungerStation reachability signal travel?
Outward from the restaurant, which is the opposite of what the name suggests. Delivery Hero’s shared schemas define PosReachabilityStatus with the values online and offline, and a PosReachabilityStatusUpdate object carrying message, reason and status. Those fields exist so that a point of sale system can report its own health into the platform.
The vendor availability description works the same way: “Integration Middleware API allows Vendors to state if they are open or closed. If closed, the vendor will be marked as offline on the Delivery Hero platform and customers won’t be able to place orders.” Source: developers.deliveryhero.com.
Every verb in that sentence belongs to the vendor. State, closed, marked. A chain looking for the reverse signal, an object the platform populates when it takes a store offline, does not find one in the published schemas. HungerStation’s own outlet management API is a status you write and a status you read, and the eight closure reasons it defines are values you retrieve rather than values you receive.
Why does knowing where to look on HungerStation take four names?
Because HungerStation calls the same back office four different things in its own material, and a manager searching for guidance has to guess which one to use. The developer portal calls it Partner Portal, describing “Access to Partner Portal (our self-service portal for partners)”. The recruitment page calls it Seller Portal, promising access to “the HungerStation “Seller Portal”, where you’ll find all the information and tools you need for a successful partnership with us”. The privacy statement is headed “Privacy Statement (Vendor Portal/One App)” and refers in the body to “our vendor portal”. Source: hungerstation.com.
Naming is not usually a notification problem, and here it is one. Nothing arrives to tell an operator a branch is off, so the fallback is to go and look, and going to look requires knowing what the thing is called and which of its plugins holds the answer.
Access is not self service either. The developer documentation says the plugin permission comes from a person, “you will be given access by your account manager or during registration with us”, and adds the same for identifiers, “Please reach out to your Account Manager to get the Vendor ID.” A brand that onboarded through a manager and never asked for portal access has no viewing surface at all.
Does HungerStation warn a branch that failed to check in?
It does not, and the check in itself is dormant unless somebody requests it. HungerStation documents the feature in the same terms as its sibling platforms: “The “Check-in” feature allows you to acknowledge your scheduled opening time. By default, this feature is disabled and does not require a check-in status to be sent. To activate the check-in flow, please contact your account manager.” The behaviour once live is stated too: “This feature enables you to confirm the upcoming opening of your shop up to 30 minutes before its scheduled opening hours. If the you fail to acknowledge, the shop will remain closed even if it is scheduled to be open.” Source: developer.hungerstation.com.
Note what the feature obliges and what it does not. It obliges the shop to speak within a window. It does not oblige the platform to say anything when the window passes unanswered. The shop simply stays shut, and the first evidence is an absence of orders during hours the schedule says are open.
The merchant application is not the missing channel either. Its published pitch is about running the operation, promising to “Track live orders in real time and solve issues on the go” and to “Easily adjust your store’s opening times”, and it does not claim to raise an availability warning.
What does a twelve hour average say about who is watching HungerStation?
More than any documentation does. Across our own monitoring of HungerStation storefronts in Saudi Arabia, listings were unavailable for 2.88 per cent of published trading time with a mean interruption of twelve hours twenty four minutes. Excluding listings that had stopped trading altogether, the figures fall to 0.77 per cent and a mean interruption of five hours.
Five hours is the honest number for an actively trading branch, and it is still the longest average in any market we measure. On a platform that publishes no push, no reminder addressed to the restaurant and no auto reopen rule, a five hour mean is not a statement about kitchens. It is a statement about how long a listing can sit dark before a human happens to open the right portal under one of its four names.
The way to shorten it does not run through the portal at all. Checking whether each branch can be ordered from right now, against the hours that branch published for today, produces a timestamped interval whether the cause was a disabled integration, a changeable flag set to false, or an unanswered check in. That is the record Kitchain (kitchain.co) keeps on HungerStation listings, and it is the one artefact that survives after the branch comes back.