Some of your branches are offline on Wolt and the rest are fine
Restaurant chains on Wolt are working with venues rather than with a brand, and Wolt keeps two separate facts about each one. Its venue status object carries is_open for the schedule and is_online for whether the venue is actually taking orders, so a venue can be inside its hours and still absent. Every limit, every role and every closure on this platform is addressed to a venue, and there is no published way to bring a group of them back online at a chosen time. Estates therefore diverge one venue at a time.
Why can half your Wolt venues be open and not online at the same time?
Because the schedule and the order flow are stored in different fields. The venue status object returned by Wolt’s Merchant API carries three booleans, and two of them answer different questions: is_open reports the timetable, is_online reports whether orders are being taken at this moment. Source: developer.wolt.com.
Most platforms give a chain a single flag and leave it guessing which of the two questions it just answered. Here the pair can be read directly, so an estate sorts into three groups rather than two: venues outside their hours, venues inside their hours and selling, and venues inside their hours and not selling. Only the third group is losing anything, and it is usually small enough to act on the same day.
The merchant interface then blurs what the fields separate, since Wolt labels the control with a green dot and the word Open when a venue is ready to accept orders. Source: merchant.wolt.com. A branch manager will therefore report that a venue is open while an integration reports that it is not online, and both statements are accurate about the field each person is reading.
What does the is_ipad_free flag split an estate into?
Two populations with genuinely different failure modes, and it is worth grouping a chain by that field before comparing anything else. A venue running with a Wolt tablet depends on that device staying awake. A venue running without one does not.
Wolt is direct about the risk, warning that “Some tablets go offline after about 20 minutes of no activity” and advising merchants to check the device during the day. Source: merchant.wolt.com. Note the hedging in that wording. Some rather than all, and about twenty minutes rather than a committed number, which tells you Wolt is describing hardware behaviour it does not control.
Across a group that means one half of the estate has an availability dependency the other half does not have at all, and it is a dependency nothing reports. No head office tool knows whether an application is in the foreground on a screen in a branch, so the venue keeps every appearance of trading right up to the point a customer looks for it.
The routine part is automated, since Wolt states that the application opens and closes a venue against the hours the merchant set. Automation is why the failure is so hard to see. Where a venue has opened itself for two years, nobody in that branch has ever had a reason to check that it did.
Why does an omitted until value leave one venue behind indefinitely?
Because Wolt reads a missing end time as a deliberate instruction rather than as an omission. The endpoint accepts ONLINE and OFFLINE alongside an until timestamp, and the documentation states that leaving that field out, or sending it as null, sets the venue “offline indefinitely”.
An integration written without ever populating that field will therefore produce open ended closures at every venue it touches, and no error will be raised. Where one part of an estate was connected by one integrator and another part by a second, the two groups behave unlike each other for that reason alone. One group expires back into service, the other waits for a person.
Wolt then names the asymmetry outright, noting that scheduling a venue back to online status is not supported. Going dark can carry a time. Coming back cannot be booked at all.
Presets in the merchant application are the practical answer, since the short closures it offers each carry their own ending, and Wolt points merchants at the portal or at support for anything longer such as a holiday. Standardising every branch on those presets, and treating any closure without an end as an exception that needs a name attached to it, removes most of this class of problem from a group.
What does last_three_orders_status give a chain that other platforms do not?
A warning that belongs to the merchant instead of a penalty that belongs to the platform. The venue status object includes last_three_orders_status, and Wolt explains why it is there by suggesting that three rejections in a row be treated as a red flag calling for remedial action.
Set that beside the neighbours and the difference in philosophy is plain. Two platforms in this set act on the same signal themselves, closing or pausing the location automatically. Wolt hands the signal over and leaves the judgement to the partner. We looked for a published rule under which Wolt deactivates a venue for performance and found none, so this page does not claim one.
For a group that makes it an opportunity with a condition attached. The field is per venue and readable only by an integrated system, so a brand collecting it across the estate holds a leading indicator per branch, while a brand without an integration has nothing at all. Two chains on the same platform therefore have completely different amounts of warning before a branch becomes a problem.
Why is a Wolt price change or campaign not a brand level action either?
Because the same per venue scoping runs through the rest of the product. Wolt’s menu guidance states that “All limits are enforced per venue; exceeding these limits will result in 429 errors”, listing one request per fifteen minutes for each of the update and read operations. Source: developer.wolt.com. A correction pushed to forty venues is forty throttled operations, and a venue that hit its limit during a bad rollout is a venue that will be out of step for a while.
Campaigns are gated by role, and the roles are named for the two levels. Wolt states that “To create a campaign, users will need to have Access Role of ‘Merchant Owner’ or ‘Venue Owner’.” Source: merchant.wolt.com. A venue owner can act on their own venue. Anybody else, including the area manager who noticed the problem, cannot.
That role structure is the clearest statement Wolt makes about how it expects a group to be organised. Authority sits at the merchant or at the venue, with nothing in between, so a middle layer of management has visibility without the ability to act.
How should a group compare Wolt venues against each other?
Read both booleans for every venue at the same moment, and start with the venues where is_open is true and is_online is false. That set is the answer to this page’s question, and everything else is context for it.
Then separate the tablet venues from the tablet free ones, because the remedy differs. A tablet venue that goes offline in the same part of the day repeatedly is reporting a device going idle, and the fix is a habit or a charger. A tablet free venue in the same state is reporting an integration or a closure without an end time, and the fix is in the software.
Neither reading gives you the past, because the status object only describes the present moment. A venue that lost three hours yesterday and a venue that has not moved in a month return the same answer today. Rebuilding the missing half means recording orderability over time, venue by venue, against the hours each venue published, which is what Kitchain (kitchain.co) collects across a Wolt estate from the customer side.
A final caution for group reporting. Because this platform separates the timetable from the order flow, a Wolt availability figure counts a narrower event than a figure taken from a platform with one combined flag, so the two should never be averaged together in a board pack.