Why your Ninja menu prices differ from the ones you set

Restaurant operators on Ninja do not change a price so much as ask for one. The interface of Ninja’s partner portal says so in three places: editing a product variant returns “Product Variant update requested successfully”, a change to a menu object returns “Change requested! and it will reviewed by admin shortly.”, and the portal carries a standing notice that “Some updates have been made that require an approval before they can be published.” Where a menu arrived through an integration the portal refuses the edit outright, with “Integrated products can’t be edited”.

Does the Ninja partner portal let a restaurant change a price directly?

Not in the way an operator expects. Everything quoted on this page comes from the interface of the Saudi partner portal at restaurant-portal.ananinja.com, read from the interface dictionary it serves, so these are the words the portal shows a restaurant rather than statements from any Ninja documentation. Ninja publishes no partner documentation of menu mechanics that we could find, which makes the interface the only first party evidence available.

Read as a group, the strings describe a review queue rather than an edit form. Creating something returns “Request has been created! and it will reviewed by admin shortly.”, changing something returns “Change requested! and it will reviewed by admin shortly.”, the portal has a labelled view called “Requested Changes”, and even a branch location update returns “Map update requested successfully!”. The seasonal hours screen makes the same point in full sentences, telling the operator that the system “will activate them after approval”. A restaurant using this portal is submitting, not publishing, and the gap between submission and approval is a period in which the customer sees the old number.

What does Ninja’s portal do when the menu came from an integration?

It locks the menu at every level, and it has a separate refusal message for each one. The portal groups these strings under a key named external_not_allowed, and the group is unusually thorough. At the top, “Integrated menus can’t be edited” and “Can’t add categories to integrated menus”. One level down, “Integrated categories can’t be edited”, “Can’t add products inside integrated categories” and “Can’t link products to integrated categories”.

The cascade continues to the bottom of the menu tree. For items: “Integrated products can’t be edited”, “Can’t add toppings inside integrated products”, “Can’t link toppings to integrated products”, “Can’t delete toppings from integrated products” and “can’t edit variants of Integrated products”. For modifiers: “Integrated toppings can’t be edited”, “Can’t add topping options inside integrated toppings”, “Can’t edit topping options of an integrated topping” and “Can’t add topping options to an integrated topping”. Even the picker is closed, with “can’t select an integrated item” shown on the search dropdown.

Fifteen separate refusals across five levels is not a warning, it is a design decision. Once a menu is marked external, and the menu information panel carries a field labelled “External”, the portal stops being a place where a price can be corrected. The restaurant’s own login is then the wrong tool for the job, and every minute spent in it is wasted while a wrong price is live.

Which numbers make up a price on Ninja?

More than one, which is the second reason a Ninja figure can differ from the price book. The portal’s item fields include “Unit Price” and, separately, “Container Price” with its own input prompt, “Enter container Price”. There is a plain “Price” field with “Enter price”, and a conditional labelled “Have a price ?” that implies items which carry no price of their own. Delivery is a further line, labelled “Delivery price”.

On top of those sit two discounts with different owners. The portal has a “Platform Discount” field prompting “Enter platform discount” and a “Restaurant Discount” field prompting “Enter Restaurant Discount”. A restaurant reporting that its Ninja price is wrong is therefore making a claim about a total assembled from a unit price, a packaging charge and two discounts, only some of which it controls. Reconciling the displayed figure to a single menu number will fail whenever a platform discount is running, and nothing in the interface tells the operator one is.

What does the Ninja portal record when a menu changes?

A change log, and its contents are revealing for what they leave out. The portal can describe a modification with one of ten phrases: “Changed the allergens”, “Changed the Arabic Description”, “Changed the Arabic name”, “Changed the English Description”, “Changed the English name”, “Changed the images”, “Changed the Location”, “Changed the menu”, “Changed the Time Slots” and “Changed the weight”. Price is not among them, in either the English or the Arabic dictionary.

Menus are also versioned. The interface has “Current Menu”, “Current Version”, “Previous Versions” and a “Draft” state, which means a restaurant can be looking at a version that is not the one customers are being served. Those two facts combine badly. If a price moved and the change log has no vocabulary for saying so, the person investigating cannot establish from the portal when the price changed or who changed it, only that the current version differs from what they expected.

Why does adding an integrator make a Ninja price harder to fix, not easier?

Because the integration is what locks the portal, and the handover itself can rewrite the menu. Deliverect’s help article on adding stores warns that when menus are selected for publishing, “Doing this overwrites the existing menu on your ordering channel”, and advises making the menu complete on the integrator’s side first (help.deliverect.com). For a brand that spent weeks building a Ninja menu in the portal, the first publish through middleware is the moment those prices can be replaced wholesale.

The speed makes it easy to underestimate. Deliverect lists Ninja as activating “Within 48 hours” of a request, the fastest band in its Middle East table alongside Keeta, while several regional platforms in the same list take up to a week (help.deliverect.com). A change of source that takes two days to land, and after which the portal answers price questions with “Integrated products can’t be edited”, deserves more preparation than a two day timeline invites.

How do you find a wrong Ninja price when the portal will not let you change it?

By reading the customer view, because on this platform it is both the authority and the only surface that is never locked. The portal will show a restaurant its own draft, its own requested changes and its own version history, and none of those answers the question of what a customer is being charged right now. Note also that the portal’s country list covers Bahrain, Kuwait, Qatar and Saudi Arabia, so a brand operating across the Gulf may be reconciling several catalogues that were never expected to match.

For a chain this makes price checking an observation job with a clock on it. Every price change is a request with an unknown approval time, so the useful measurement is not whether the request went in but when the storefront finally showed the new number. Kitchain (kitchain.co) reads live Ninja menus from the customer side and compares them against the brand price book, which on a platform whose own change log has no word for price is the only record that shows the gap and its duration. The rest of what we track on this platform sits on our Ninja page.