Some of your branches are offline on HungerStation and the rest are fine
Restaurant chains on HungerStation are working with vendors that were configured individually and can hold different rights. The status endpoint is addressed to a chain and then to a single vendor inside it, the check in feature is switched on per vendor by an account manager, and the Delivery Hero middleware behind the platform carries a flag that says whether a given vendor is even allowed to change its own availability. Three branches of one brand can therefore hold three different sets of powers over the same button.
Why is the HungerStation status endpoint addressed to a chain and a vendor at once?
Because that is the shape of the data model, and it tells you where settings actually live. The production endpoints are PUT /v2/chains/{chain_id}/vendors/{vendor_id}/status and the matching GET, on the host HungerStation names in its integration guide. Source: developer.hungerstation.com.
A chain identifier exists, and nothing hangs off it except a list. Every state that decides whether a customer can order sits one level down on the vendor. The status values HungerStation publishes for writing are “CLOSED_TODAY”, described as the vendor being closed till the end of the day, “CLOSED_UNTIL”, closed till the date specified in the closed_until field, “OPEN”, which opens a closed vendor only if it is within opening hours according to schedule, and “CHECKIN”. Reading a vendor back adds “CLOSED”, described as the vendor closed without an end date. Source: developer.hungerstation.com.
That last one is the state that outlives a shift. A vendor in “CLOSED_TODAY” rejoins its schedule tomorrow. A vendor in “CLOSED” has no end attached, and one branch in that state alongside nine in normal operation is exactly the pattern this page is about.
Check in on HungerStation is switched on per vendor, not per brand.
HungerStation documents the feature and the way it is enabled in the same paragraph: “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.” It then states the consequence: “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.
Read the enabling route rather than the feature. It is off by default and turned on by a human, one account at a time. An estate onboarded across three years, through three different account managers, will not have it uniformly configured, and nobody at the brand necessarily knows which branches carry it.
The operational effect is a morning that differs between branches for no visible reason. Where check in is off, the schedule opens the shop. Where it is on and nobody acknowledged, the shop stays closed while its schedule says otherwise. Both branches did the same thing. Only one of them is selling, and the documentation adds that the shop can still be opened by calling the API with an “OPEN” status, which requires somebody to know it is shut.
Why can one HungerStation branch be refused the right to change its own status?
Because the Delivery Hero middleware that sits under the platform decides that per vendor, and publishes the flag. The OpenAPI for the integration middleware instructs integrators that “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.” Both changeable: false and changeable: true appear in its examples. Source: integration middleware OpenAPI.
A brand that has never inspected that field will assume every branch has the same powers. It does not necessarily. A vendor whose availability is not changeable will fail every attempt made against it, and the failure is a rejected request rather than an error anybody in the kitchen can see.
The same layer describes the platform switching an integration off. Delivery Hero states that “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”, and more broadly that “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. Neither sentence is about a kitchen, and both can leave one part of an estate connected and another part not.
Do all your HungerStation branches offer the same closure durations and reasons?
Not necessarily, and the middleware returns the answer per vendor rather than as a constant. Its GET response carries a list of permitted closing durations, with 30, 60, 120, 240 and 720 minutes appearing in the examples, alongside a list of permitted closing reasons for that specific vendor.
HungerStation’s own published set of reasons is fixed and worth knowing, because it separates causes that most platforms merge. The closed_reason enum reads “TOO_BUSY_NO_DRIVERS”, “TOO_BUSY_KITCHEN”, “UPDATES_IN_MENU”, “TECHNICAL_PROBLEM”, “CLOSED”, “OTHER”, “BAD_WEATHER” and “HOLIDAY_SPECIAL_DAY”, and the field is described as “The reason why the vendor had been closed. Will be omitted if the vendor status is OPEN”.
Two of those eight describe conditions outside the restaurant entirely, since a shortage of riders and bad weather are not decisions taken in a kitchen. That matters for a split estate because both are local. A branch in one district can be closed for want of couriers while a branch across the city trades, and a brand reading only its own operational reports will see one branch underperforming rather than one district under strain.
How do you tell a dark HungerStation branch from a listing that never trades at all?
By measuring the two populations separately, which is the single most important habit on this platform. Our July 2026 Saudi panel showed HungerStation listings losing 2.88 percent of stated trading hours with a mean incident length of 12 hours 24 minutes. Excluding listings that were never actively trading, the same panel gives 0.77 percent and a mean incident of 5 hours. Both pairs are published in our Saudi delivery downtime report.
The gap between those two readings is the size of the problem being described here. A chain that pools every listing under one brand name will conclude that a third of its estate is unreliable, when part of what it is looking at is cards that have not traded for months, left behind by a closed branch, a rebrand or a duplicate registration.
Separating them is a matter of history rather than of status. A branch that traded yesterday and is dark today is an incident. A card that has not been orderable in any recent window is an inventory problem, and it should be removed from the availability denominator before anybody is asked to explain a number.
What should a Saudi chain compare between two HungerStation vendors?
Four things, in this order, because each one can produce the symptom on its own. Whether check in is enabled on that vendor. Whether the vendor’s availability is changeable at the middleware layer. Which closure reason the vendor is carrying, since two of the eight point outside the restaurant. And whether the vendor is a live listing at all or a card left behind.
None of those four is visible from a kitchen, and only the third is visible in a normal partner view. The portal itself is not a single door either, since HungerStation names it “Partner Portal” in its developer material, “Seller Portal” on its partner recruitment page and “Vendor Portal” in its privacy statement, and access to its plugins is granted by an account manager rather than claimed by the brand. Because the estate is uneven by configuration rather than by conduct, the only comparison that holds is a per vendor record of when each listing could actually be ordered from, measured against the hours that listing published, which is what Kitchain (kitchain.co) collects across a HungerStation estate.