How to get Wolt to put your restaurant back online
Restaurant chains on Wolt are returning a venue with one write and no way to plan it in advance. The API takes a status field described as “The new store status to use”, with ONLINE and OFFLINE as the permitted values, and Wolt states the limitation in its own sentence: “Scheduling for online status is not supported yet.” An offline venue therefore comes back at the moment somebody acts, never before. The complication is that Wolt keeps two separate facts about a venue, and a return only fixes one of them.
Setting a Wolt venue ONLINE is the only documented way back
The venue endpoint accepts the two values above and pairs them with an until field described as “The date and time (ISO 8601 format) when the venue is to be set offline. Use null or omit the field completely to set venue offline indefinitely.” Source: developer.wolt.com.
Read the asymmetry carefully, because it is the whole risk profile of this platform. Going offline can carry an expiry. Coming back cannot be booked. So every closure created without an until value is a state that lasts until something else ends it, and Wolt names that outcome with the word indefinitely rather than leaving it implied.
The practical rule that follows is short and applies to integrators and to staff equally. Never create an open ended offline on Wolt. If the closure has a known end, put it in the until field and let the platform perform the return. If it does not have a known end, the person who created it owns the return personally, and that ownership needs handing over at the end of a shift.
Which of the two Wolt booleans are you actually trying to change?
An ONLINE write moves one field and leaves the other alone. Wolt keeps the timetable and the order flow in separate booleans, is_open and is_online, and what that split means for a listing is set out on why a Wolt venue shows as offline while the restaurant is open. For a return the only question is which of the two is currently false, because the two states have different remedies and only one of them answers to the control described here.
Read the pair before touching anything. A venue outside its published hours will not start selling because somebody set it online, and repeating the write will not change that. A venue inside its hours with is_online false is the case the write exists for. Getting this the wrong way round costs the most common wasted hour on this platform, spent pressing a control that was never the blocker while the actual fix sits in the opening hours screen.
A third field decides who has to be standing in the branch. is_ipad_free tells you whether the venue runs without a Wolt tablet, and that changes who can perform the return at all. A tablet free venue can be brought back by whoever holds the integration, from anywhere. A tablet venue cannot be returned reliably from head office, because the device is part of the dependency, which is the subject of the next section.
The merchant app presets are the safe way off, because each carries its own return
Wolt offers a short closure of 30 minutes, 1 hour, or until the next scheduled opening. Every one of those has an ending built into it, which means a venue closed with a preset will return without anybody remembering to act. That makes the presets the correct instruction for branch staff in almost every situation.
The dangerous action is the open ended one, and it arrives from two directions. An integration that sets a venue offline without an until value has created one. A member of staff who used a route other than the presets may have created one too, and neither leaves a countdown on the screen to warn the next shift.
For a chain the useful policy is therefore not about availability at all, it is about which control staff are allowed to touch. Presets only, at branch level, with anything longer escalated. That single rule removes most of the indefinite states a group would otherwise accumulate, and it costs nothing operationally because the presets cover the real cases, which are a kitchen incident, a delivery failure and the end of a shift.
Wake the tablet before you set the venue online
Because on Wolt the device is a live dependency rather than a display, and the platform says so: “Some tablets go offline after about 20 minutes of no activity. To avoid this, just check your tablet a few times a day to make sure the app is on and your venue is online.” Source: merchant.wolt.com.
For a return, that sentence fixes the order of work: device first, status second. A venue set online while the application is closed or the screen is asleep drops out again without anybody deciding anything, and the second departure arrives with no more warning than the first. From head office the sequence reads as a branch that keeps changing its mind, while the person who performed the return will insist, correctly, that they performed it.
That is also why a Wolt return is not finished at the moment the write succeeds. Confirmation lives on the consumer side rather than in the response, so the honest end of the procedure is somebody seeing the venue orderable, not somebody seeing an acknowledgement. On a tablet venue the shortest reliable script has three steps in a fixed order: the branch opens the application and reports what the screen was doing, then the status is set, then the public listing is checked by a person who is not the one who set it.
When does a Wolt closure have to go through the portal or Wolt support?
For anything longer than the presets. Wolt points merchants at the portal or at Wolt support for extended closures such as holidays, which makes a planned absence a task to complete in advance rather than an action available on the day.
What Wolt does not publish alongside that is a response time, a ticket category or an escalation path, so a brand planning a refit should raise it early and confirm it rather than assuming a same day turnaround. We looked for those and they are not in the published material.
The missing turnaround has one practical consequence for any return that needs Wolt’s help. There is no published moment at which a request becomes late, so nothing escalates itself, and a venue waiting on the portal can sit in the same state on the third day as on the first without any threshold being crossed. A chain raising these should keep its own clock against them, logging when the request went in and what the venue was doing meanwhile, because that log is the only thing that turns a wait into a fact two parties can discuss. Nothing Wolt publishes describes the platform taking a venue offline on its own, so the return is addressed to whatever inside the business created the state.
What should you check after a Wolt venue has been set online?
Both booleans, and then the storefront. Setting the status is a single action with a single effect, and everything that can undo it lives somewhere else: the schedule, the tablet, the application state and, for an integrated brand, whatever process set the venue offline in the first place.
The measurement that closes a return is therefore not the write, it is the gap between the write and the venue becoming orderable to a customer. A venue that was set online and then stayed quiet has probably not come back, and on a platform with no scheduled reopening there is nobody due to look at it a second time. Kitchain (kitchain.co) times Wolt returns from the customer side, recording the minute a venue became orderable rather than the minute somebody pressed the control, because those two are the same number only when everything worked.
One instruction belongs in the shift handover rather than in any monitoring tool. Whoever creates a closure on Wolt owns the return in person unless they gave it an until value, and that ownership has to pass to a named individual at the end of a shift. Every other rule on this page is downstream of that one, because the platform will not perform a return that nobody booked.