Some of your branches are offline on Talabat and the rest are fine
Restaurant chains on Talabat are working inside a chain identifier that mostly does nothing. Talabat addresses availability at PUT /v2/chains/{chain_id}/vendors/{vendor_id}/status, so the chain is a container and every state that decides whether a customer can order belongs to a single vendor underneath it. The platform will happily apply a promotion to every vendor at once through a wildcard, and offers no equivalent for opening or closing. That asymmetry is the reason a Talabat estate ends up in several states on the same evening.
Why does Talabat give a chain a wildcard for promotions and none for availability?
Because the two features were built for different jobs, and the difference is visible in the specifications. For promotions Talabat documents the vendors field as mandatory and describes the shortcut: “Set of vendor IDs relevant to the promotion. If vendors = [“*”] promotion will be applied to all vendors associated with the chain”. Source: developer.talabat.com.
Availability has no such option. The status endpoint takes one chain identifier and one vendor identifier, and changes the state of that vendor only. A brand switching twenty branches switches them twenty times, whether by a script, by twenty tablets or by twenty people, and any one of those twenty can be missed without producing an error anywhere.
That is the structural answer to why part of an estate is dark. There is no operation on this platform whose success would guarantee that all branches are in the same state, so nothing ever asserts that they are.
The same specification also carries the honest version of what a promotion job returns, with fields named invalid_vendors, missing_skus and invalid_discounted_skus, described as providing details about vendors or items that will not be included in the promotion due to an error. Even the feature with a wildcard reports partial success as normal.
Talabat shows customers a Busy label, and that is a free signal for a chain.
Talabat is unusual in this category because its consumer surface names the intermediate state out loud. The storefront serves its localisation dictionary in the page itself, and the entries include restaurantBusy set to “Busy”, restaurantClosed set to “Closed”, restaurant_busy_message set to “is Busy at the moment” and restaurant_closed_message set to “is Closed at the moment”. Source: talabat.com.
Two labels rather than one means an estate can be sorted from outside without any account access. A branch showing busy is present, visible and slowed. A branch showing closed is present and not selling. A branch showing neither is not on the page at all, which is a third case again and usually the most serious.
Compare that with Careem Food, where the word busy does not exist in the partner portal at all and a branch that stops selling simply disappears from the listing. On Talabat the customer facing vocabulary does part of the diagnostic work for you, and a chain that never looks at its own storefronts is throwing that away.
The partner side uses the same language. Talabat’s partner FAQ answers the question “Can I stop orders if it gets too busy?” with “Yes, our partners can pause orders at any time. Using our tablet, you can pause your store from collecting orders for a specific time period. You can also indicate that your store is busy, letting customers know to expect longer prep times.” Source: ae.partner.talabat.com.
Which closure reason is each Talabat vendor carrying, and who set it?
Talabat publishes eight, and they are the most useful field on the endpoint. 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”, with the field described as “The reason why the vendor had been closed. Will be omitted if the vendor status is OPEN”.
Sort an estate by that field and the answer to this page’s question usually falls out in one pass. Two of the eight describe conditions outside the restaurant entirely, since a shortage of riders and bad weather are not decisions taken in any kitchen, and both are local, so they hit branches in one district and not another. One names the integration directly. One names menu work, which is scheduled and therefore predictable.
The reason is attached to the vendor rather than to the chain, which means it is only readable per branch. A group that collects it centrally can distinguish a district problem from a branch problem in minutes. A group that does not is left comparing revenue.
Talabat’s own integration material confirms the same layer exists for POS, stating “Use Store Management API to manage the availability of stores on Talabat”. Source: integration.talabat.com. Availability driven by an integration and availability driven by a tablet will produce different reason codes for identical customer experiences.
Why can a Talabat vendor sit in a state your own tools cannot create?
Because the readable set of statuses is wider than the writable one. Talabat documents the values accepted on a write as “CLOSED_TODAY”, the vendor closed till the end of the day, “CLOSED_UNTIL”, closed till the date 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 can also return “CLOSED”, described as “the vendor was closed without end date”.
That extra value is exactly the state that survives a shift. A vendor closed for the day rejoins its schedule tomorrow. A vendor closed until a timestamp comes back at that timestamp. A vendor in the state with no end date comes back when somebody acts, and one branch in that condition alongside nineteen normal ones is the pattern this page is about.
The opening rule adds a second trap for the branch trying to rescue itself, since “OPEN” is documented as working only inside the schedule. A branch whose hours say it should be shut cannot be opened by the obvious call, and the fix is in the schedule rather than in the status.
Check in is a further per vendor switch. Talabat states that the feature is disabled by default, that activating the flow requires contacting an account manager, and that the “CHECKIN” status “works only if checking feature has been enabled for the vendor”. Branches onboarded at different times will not have it configured the same way.
What does the tablet in each branch decide on Talabat?
More than most head offices assume. The partner FAQ names the tablet as the place where a store is paused for a specific period, and Talabat’s group level integration material refers to the device on the counter as the Delivery Hero Vendor App, the application on hardware provided by the platform.
One device per branch means one independent switch per branch, and it is held by whoever is on shift. That is not a criticism of the design, since the person nearest the kitchen is the right person to pause it. It is a statement about where an estate’s availability actually lives, which is on twenty counters rather than in one dashboard.
It also explains why the same brand can show every combination at once on a Friday evening. One branch busy because someone chose it, one closed for the day because someone chose that instead, one closed with no end date from an earlier shift, one closed because riders are short in that district, and the rest trading normally.
How should a Gulf chain compare vendors inside one Talabat chain id?
Read every vendor at the same minute, and read three fields rather than one: the status, the reason where a reason exists, and the schedule for that vendor on that date. Then confirm against the storefront, because the customer facing labels quoted above will tell you whether a branch is busy, closed or absent without any account access.
The market numbers are worth holding while you do it. In our July 2026 panel, Talabat listings in the UAE lost 1.81 percent of stated trading hours with a mean interruption of 3 hours 34 minutes, the longest average interruption of the UAE platforms we measured, while in Kuwait the same platform lost only 0.09 percent with a mean interruption of 36 minutes. The same brand operating in both markets should expect very different shapes from the same tooling.
Because an interruption here averages more than three hours in the UAE and the platform provides no way to assert that all branches share a state, the number that matters is the gap between a branch changing state and somebody noticing, measured per vendor against that vendor’s own published hours, which is what Kitchain (kitchain.co) collects across a Talabat estate.