How to get Talabat to put your restaurant back online
Restaurant chains on Talabat bring a vendor back by writing a status rather than by asking anyone, and there are two different writes that do it. The ordinary one is OPEN, documented as “open closed vendor if it’s within opening hours according to schedule”, which means the weekly schedule holds a veto over the return. The other is CHECKIN, which acknowledges a scheduled opening and only exists where the feature has been switched on for that vendor. Knowing which of the two a situation needs is most of the recovery.
Talabat’s return is a status write and the schedule can veto it
The endpoint is PUT /v2/chains/{chain_id}/vendors/{vendor_id}/status on the production host https://talabat.partner.deliveryhero.io, and the values it accepts are CLOSED_TODAY, CLOSED_UNTIL, OPEN and CHECKIN. Source: developer.talabat.com.
The two closing values carry their own endings. CLOSED_TODAY is documented as meaning the “vendor will be closed till the end of the day”. CLOSED_UNTIL is documented as closed “till the date specified in closed_until field”, where that field is described as a UTC timestamp in ISO 8601 format and is omitted for every other status. A closure written with either of those has a defined boundary, which is why the deliberate way to pause a Talabat vendor is always with one of them rather than with an open ended action.
What Talabat does not publish is a statement that a closed vendor reopens automatically. The end of day meaning of CLOSED_TODAY implies a boundary and is not the same as a documented promise, and we are not going to present it as one. The only documented way back into trading is the OPEN write, and it is conditional on the schedule.
Which Talabat surface sends that status, and which one is in the branch?
Three, and they are not equally reachable during a service. The Partner Portal, which Talabat calls the “talabat Partner Portal” and elsewhere “talabat’s Vendor Portal”, is the desk surface, reached at partner-app.talabat.com with country specific addresses alongside it. The Partner App, listed in the stores as “talabat partner”, is the same account on a phone. The tablet in the branch runs what Delivery Hero calls the “Delivery Hero Vendor App”.
Talabat describes the tablet route in its own partner FAQ, answering the question of stopping orders during a rush 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.
Note the phrase “for a specific time period”, which matches the API design. The safest habit on Talabat is that every pause carries a duration on the way in, because the return then belongs to the clock rather than to somebody’s memory. For integrated brands the same job is described on the integration side as using the Store Management API “to manage the availability of stores on Talabat”. Source: integration.talabat.com.
CHECKIN and OPEN are two different returns, and only one needs enabling
The distinction is worth teaching because from a customer’s phone the two look identical. A vendor that never opened at its scheduled time was not closed by any decision, so there is nothing to undo, and the ordinary reopen does not obviously apply to a shop that was never shut. Branch staff faced with that reasoning tend to wait, or to raise a ticket, and both cost the whole morning.
Talabat settles it in a single sentence: “However, the shop can still be opened by calling the API with a ‘OPEN’ status.” A missed acknowledgement therefore needs neither a support request nor a wait for the next check in window. It needs the ordinary open, sent by whoever noticed, and that one sentence saves more time on this platform than any other line in the specification.
Check-in is not on by default. Talabat states that “By default, this feature is disabled and does not require a check-in status to be sent” and that activating it goes through an account manager. That produces a diagnostic question a brand should be able to answer in advance rather than during an incident, because a vendor with check-in enabled and a vendor without it fail to open for completely different reasons, and only one of those is fixed by changing a routine.
Reading closed_reason tells you whether the return will hold
A closed Talabat vendor carries a closed_reason, described as “The reason why the vendor had been closed. Will be omitted if the vendor status is OPEN”. The eight values it can hold are set out on why a Talabat store shows closed while the restaurant is open.
Sort those by whether reopening solves anything. TOO_BUSY_KITCHEN and UPDATES_IN_MENU describe conditions inside the restaurant, and a vendor reopened while either is still true will be closed again shortly. TOO_BUSY_NO_DRIVERS and BAD_WEATHER describe the delivery network rather than the kitchen, so reopening may be pointless until the network recovers. TECHNICAL_PROBLEM is the one that most often hides an integration fault, since it is the code an integration is expected to send when it cannot process orders.
For a brand that reads the field before acting, this converts the reopen decision from a reflex into a judgement. For a brand that does not read it, every closure looks the same and the recovery is a coin toss between a fix that holds and one that lasts four minutes.
What to raise with a Talabat account manager, and what Talabat has not published
Talabat routes several things to an account manager by name, including activation of the check-in flow, and it names its in portal support as the “Help Center of the Partner Portal”. What it does not publish anywhere is a statement that Talabat itself suspends a restaurant, a procedure for lifting such a suspension, a response time, or an escalation path for a vendor that cannot be reopened. We checked the partner site, the corporate FAQ and the developer specification, and none of the three contains it.
That absence changes what a request should look like. Since there is no documented platform state to name, the message has to carry its own evidence: the vendor identifier, the status and reason read back from the API or the portal, the timestamp of the last order the vendor could have taken, the hours configured for that day, and whether the same brand’s other vendors were sellable at the same moment.
Leave compensation out of it. No Talabat document publishes a rule for downtime not caused by the restaurant, and raising it turns a factual report into a negotiation nobody on the other end is authorised to have.
What should a Gulf chain watch after a Talabat vendor is reopened?
Whether it stayed open, measured against the hours that vendor published. A reopen here is one write against a state that several different things are capable of recreating, so the question after a return is not whether the write succeeded but whether the vendor was still selling an hour later. A brand that checks once, at the moment of the fix, has checked the only minute in which the answer was guaranteed.
Set the target against the mean rather than against the incident. A Talabat listing in the UAE lost 1.81 percent of its trading time in July 2026 with a mean interruption of 3 hours 34 minutes, so a return completed three hours after a closure is an ordinary result on this platform rather than a poor one, and a brand that wants to be better than ordinary has a number to beat rather than a feeling to argue about. Neither figure appears inside the Partner Portal, which reports the present rather than the interval, and rebuilding the interval from the customer side is what Kitchain (kitchain.co) does across Talabat vendors.