Why your DoorDash menu prices differ from the ones you set

Restaurant operators on DoorDash are often correcting a price in a place DoorDash itself says will not hold. For a POS integrated store DoorDash states that “Changes made through the Menu Manager in the DoorDash Merchant Portal are not permanent and may be overwritten by updates from your POS or cause orders to fail”. The authoritative route is slower, since “Your pricing change will be reflected on DoorDash as soon as your POS pushes your new prices to DoorDash. This typically occurs within 24 hours.”

Where does a DoorDash price change actually take effect?

DoorDash runs two editing routes and is unusually blunt about which one wins. Its integration guidance states that “Your POS menu should be your primary source for menu updates” and that “Changes made through your POS menu are directly synced with your DoorDash menu”, followed by the warning that portal edits “are not permanent and may be overwritten by updates from your POS or cause orders to fail” (help.doordash.com). Its pricing article says the same thing from the other end, that “Merchants are responsible for setting their pricing on DoorDash” while the change itself arrives only when “your POS pushes your new prices to DoorDash”.

This produces a distinctive DoorDash pattern that is easy to misread as a platform bug. A manager fixes a price in the Merchant Portal, sees the correct number on screen, and the storefront reverts at the next sync. Nobody made a second change, and no error appears anywhere, because from DoorDash’s point of view the portal edit was always provisional. The phrase worth noticing in that warning is “or cause orders to fail”, since a portal edit on an integrated store can break order transmission as well as pricing.

How long does a DoorDash price change take to appear?

There are three published timings and they are far apart. The API route is fast, with DoorDash stating that “Average menu processing time is less than 1 minute” for a menu job (developer.doordash.com). The POS route is slow, described as taking effect “as soon as your POS pushes your new prices to DoorDash”, which “typically occurs within 24 hours” (help.doordash.com). Those two are far enough apart that a brand running both routes across its estate will see the same price change land on different days in different branches.

The twenty four hour figure is the one to plan against, and note what it is attached to. DoorDash describes it as how long the POS takes to push, not as how long DoorDash takes to publish, so nothing in that sentence promises that a price visible in the back office is the price a customer is being shown. A team that changes a price in the till and then checks the Merchant Portal is confirming its own instruction rather than the storefront, which is why the customer facing listing is the only reliable confirmation on this platform.

What does a DoorDash menu webhook tell you when a price fails?

Less than the payload size suggests, and the shape of the answer is the point. DoorDash requires a menu status webhook and describes the payload as carrying an event type of MenuCreate or MenuUpdate, a status of SUCCESS or FAILURE, a reference, and a details field that “provides a simple, actionable failure reason, enabling external partners to understand why the menu job failed DoorDash validation” (developer.doordash.com).

There is no partial state in that enum. A DoorDash menu either publishes or does not, so unlike Talabat, which returns rejected items individually, or HungerStation, which reports per SKU on the catalog side, DoorDash gives one verdict for the whole menu. In practice that is a mixed blessing. It removes the silent partial import, and it also means a single bad row takes down a whole price rollout. DoorDash documents exactly that, warning that “If a field within the menu payload exceeds the allowed Max Length, the menu will fail with a 400 Bad Request response”, with a worked example rejecting a menu for a duplicate merchant id on one item.

There is one more place a DoorDash price can come from that operators tend to forget. Menu changes requested through the portal’s Help section are completed by DoorDash staff rather than by the restaurant, within the stated 72 hours, which means a price on a DoorDash listing may have been typed by someone at DoorDash working from a request written days earlier. On a POS integrated store that value then survives only until the next sync overwrites it.

Does DoorDash require your app prices to match your restaurant prices?

No, and DoorDash says so directly, which sets it apart from Deliveroo’s UK terms and from Careem Food. Its published position is that “DoorDash does not require restaurants to match in-store prices on delivery orders” and that “Restaurants can continue to make their own delivery menu pricing decisions and assess the trade-offs between volume and unit margins” (about.doordash.com). Elsewhere DoorDash confirms that “Merchants are responsible for setting their pricing on DoorDash”.

The pressure is commercial rather than contractual. DoorDash states that “menu markups can negatively impact customer conversion and retention”. It stops short of a rule, though: “While DoorDash does not require delivery prices to match in-store, we recommend pricing as close to in-store as possible”. So on DoorDash an operator has to decide a markup rather than defend one, and the risk of an unnoticed price drift is that the brand ends up with a markup it never chose on some branches and not others.

How does DoorDash mark an item that is out of stock?

DoorDash uses the kitchen’s own word for it. Its documentation explains that “Item 86ing & Item Option 86ing refer to the act of marking an item or an item option (i.e. modifier) out of stock, making it temporarily unavailable on the DoorDash menu”, handled through dedicated status endpoints with an is_active boolean set to false (developer.doordash.com). DoorDash also ties the route to the reversal: “If you mark an item out of stock using DoorDash’s self-serve menu editor, you’ll need to re-enable the item using the same method”.

DoorDash separates this from a menu update and warns about the difference in its own words: “Note that Item 86ing and Item Option 86ing are immediate and temporary updates to the menu—this is different from permanently deactivating or removing an item using a menu_push.” There is no documented automatic restock, so an 86’d item stays 86’d until someone sets is_active back to true. For price work that is a compounding problem: an item suspended weeks ago is invisible to customers, invisible in revenue, and carrying whatever price it had when it went out of stock.

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

Establish whether the store is POS integrated before touching anything, because on an integrated store the Merchant Portal is the wrong tool and using it can affect order transmission. If it is integrated, the price has to change in the till and then wait out the sync, which DoorDash puts at up to 24 hours. If it is not, check that the last menu job returned SUCCESS rather than FAILURE, since a rejected menu leaves the previous prices entirely intact and produces no partial result to inspect.

Then remember that the twenty four hours DoorDash publishes describes the till pushing, not the storefront publishing, so the back office confirms an instruction rather than a result. That gap is the reason this particular platform rewards checking the customer-facing menu rather than the back office, which is what Kitchain (kitchain.co) reads branch by branch each day and compares against the brand’s price book. Ownership, markets and the wider set of DoorDash signals are covered on the Kitchain DoorDash page.