Why your Wolt menu prices differ from the ones you set

Restaurant operators on Wolt did not build the menu they are trying to correct. Wolt states that “Your menu will be created for you by our experienced menu specialists during the onboarding process” and invites partners only to “make minor adjustments yourself directly through your merchant account”. For integrated venues the door closes further, since “If your Wolt menu is linked to a POS system, direct edits through the menu editor aren’t possible”. Wolt also caps menu and item updates at one request per fifteen minutes for each venue.

Who wrote the prices on your Wolt listing?

Wolt’s onboarding model puts the first version of the menu in its own hands. Its merchant FAQ answers the question of creating a complete new menu with “Your menu will be created for you by our experienced menu specialists during the onboarding process”, and adds that “If your entire menu has changed, we recommend that you contact our restaurant team”, asking partners to send the new menu including the “Price of the item” among other details (merchant.wolt.com FAQ).

That division survives past onboarding. Small changes are the operator’s to make and large ones are handed back to Wolt, and the boundary between minor and entire is not defined anywhere public. For a chain, the practical consequence is that the prices on a Wolt listing have at least two possible authors and no visible record of which one set any given number, so a mismatch investigation cannot start from the assumption that someone at the brand typed it.

Where do you edit a Wolt price, and when can you not?

In the Merchant Portal, in a tool Wolt calls the “Listing manager”. The documented route is to “select “Listing manager” in the left navigation tab”, and Wolt also offers a table view in which “The name, price/ discounted price, enabled/ disabled fields of all items are presented in a tableview and they can be edited inline” (merchant.wolt.com). Editing several prices at once is therefore genuinely quick on Wolt, which is not true of most platforms in this set.

The exception is absolute rather than advisory. Wolt states that “If your Wolt menu is linked to a POS system, direct edits through the menu editor aren’t possible. For any changes, contact your POS system provider’s support for detailed instructions on updating your Wolt menu”. Unlike DoorDash, which permits portal edits and warns they may be overwritten, Wolt simply removes the capability, so an integrated venue’s price problem is always a POS problem and never a portal one.

Why does a Wolt menu push replace everything rather than change one price?

Because Wolt’s menu endpoint is defined as a whole-menu operation. Its guide states that the create menu endpoint is used to “Create a whole menu: categories, items and options” and that “Every new menu push overwrites the previous version completely”, with the recommendation to “make sure all items and options have unique identifiers (sku or pos_id or gtin)” (developer.wolt.com).

The identifier advice is the load-bearing part. In a complete replacement, an item is only recognised as the same item if its identifier matches, so a change in how a POS generates identifiers turns an update into a delete and recreate. Everything attached to the old record goes with it. Wolt reinforces the point by splitting the work across endpoints, describing the item update endpoint as the one “to manage smaller item-level changes throughout the day, such as: Mark items as temporarily unavailable” rather than for repricing a whole menu.

Why can you only correct a Wolt price four times an hour?

Because Wolt publishes a hard throttle and applies it per location. Its guide states that “All limits are enforced per venue; exceeding these limits will result in 429 errors”, and lists the limits as one request per fifteen minutes for each of Update Items, Update Options, POST Menu and GET Menu (developer.wolt.com). Reading the menu back is throttled at the same rate as writing it.

This shapes what a bad price rollout costs on Wolt. An integration that pushes a wrong price cannot simply push again, it must wait out the window, and because the push overwrites completely there is no partial correction available in the meantime. Wolt also notes that “Menus and item updates pushed to Wolt are processed asynchronously”, so the fifteen minutes is a floor on retries rather than a measure of how long the fix takes to appear. Wolt’s own best-practice guidance follows from this, advising partners to “Cache menus locally and only re-fetch if significant updates are expected”.

What does a Wolt price actually contain?

Tax, and a currency set once for the whole menu. The Menu object requires a currency field described as the “Required. Primary currency of the menu. Three-letter ISO 4217 currency code”, alongside a required primary_language (developer.wolt.com Menu API). Currency is therefore a property of the menu rather than of an item, so a single Wolt menu cannot span two currencies.

At item level the money fields sit next to tax and availability in the same object, with price accompanied by sales_tax_percentage, alcohol_percentage, enabled, disabled_until, quantity and external_data, the last of these being the mapping key back to the POS. Because tax is carried per item as a percentage rather than applied globally, a VAT change is a menu-wide edit on Wolt, and an item created with the wrong rate produces a displayed price that is correct in the source system and wrong on the storefront.

How does Wolt mark an item you cannot sell?

With a boolean rather than a status enum, which is simpler than most platforms and slightly less expressive. The Menu API describes the capability as letting partners “mark items and options out of stock without needing to build a full fledged menu editor”, implemented through the enabled flag with an optional disabled_until timestamp (developer.wolt.com Menu API). In the portal the same action is described as selecting the item and clicking “Disable item”, and Wolt confirms that “The dish is now no longer visible and cannot be ordered until you reactivate it in the same way”.

Note what that last phrase rules out. There is no automatic overnight restock of the kind Just Eat applies to items taken off on its Orderpad, so a Wolt item disabled without a disabled_until stays disabled until a person re-enables it. An item in that state shows no price at all, which means it also cannot be checked, and a chain auditing Wolt prices will silently skip it.

What should a Wolt operator check first when the app price is wrong?

Establish whether the venue is POS linked, because that determines whether anyone at the brand can fix it in the portal at all. If it is, the correction has to come from the POS provider and will arrive as a full menu replacement rather than as an edit. If it is not, the Listing manager table view is the fastest route, and the identifier on each item is worth checking at the same time, since a changed identifier is what turns the next push into a rebuild.

Then allow for the throttle before concluding a fix failed, since one request per fifteen minutes per venue means a chain-wide correction is paced by the platform rather than by the operator. Because a Wolt price can have been set by Wolt’s own menu specialists, by a POS, or by a portal edit, the storefront is the only place those three converge, and reading it branch by branch each day against the brand’s price book is what Kitchain (kitchain.co) does. Ownership, markets and the wider set of Wolt signals are covered on the Kitchain Wolt page.