Why your restaurant is not showing in Ninja search

Restaurant chains looking for a ranking setting inside Ninja’s partner portal will not find one. The portal’s interface offers a “Sort Menu” control, which orders items inside your own menu, and a marketing section where placement is asked for rather than configured, through “Request New Top List” and “Request New Ad Banner”. Each request resolves to “Accepted”, “Rejected” or “Under Process”. Position among restaurants is not a field anywhere in the portal, so a Saudi operator has availability and approval to work with, and nothing else.

What does the Ninja portal show a restaurant about its own customer card?

A preview, and the fields on it are the interesting part. The menu screen of the Saudi partner portal at restaurant-portal.ananinja.com carries a panel labelled “App Review” alongside a “Restaurant menu” view, explained by the line “It will show the review when you add the menu”. Inside that preview the portal uses “Add to cart” and three card attributes: “Delivery price”, “Km” and “Time”. Everything quoted here comes from the portal’s own interface rather than from Ninja documentation, because Ninja publishes no partner documentation on how restaurants are ordered.

Read the preview as a statement of what the card competes on. Delivery price, distance and preparation time are the three things Ninja chose to render, and a chain has real leverage over two of them. Distance is decided by which branches exist and where, and time is decided by the preparation estimate a branch promises. A brand that has never adjusted either has left the only levers the interface acknowledges untouched, and no amount of menu work substitutes for them.

Is there any ranking control in the Ninja partner portal?

Only over your own menu. “Sort Menu” and its “Sort” and “Save” controls order categories and items within a menu, which changes what a customer sees after they have already opened your listing. It has no bearing on whether they open it. Nothing in the interface names position, rank, sort order or visibility across restaurants.

What exists instead is a request desk. The marketing section holds “Top List” and “Ad Banner”, each with a request flow described as “Request a top list that increases visits more and increases sales more” and “Request an ad banner that drives higher traffic and boosts sales more efficiently”, supported by fields for “Request Place”, “Request Type”, “Select a Schedule”, “Deal Days”, “Daily Amount” and “Pricing”. So paid placement on Ninja is negotiated and approved rather than bought at a console, and the operator’s side of it is a form and a waiting state.

What quietly takes a Ninja restaurant out of the list?

Working hours that were never activated. The portal carries a warning reading “You have some inactive working hours, activate them please.”, which describes a schedule that exists but is not in force. Beside it sits a stricter one: “You cannot open this shift because the number of hours is low. Increase the number of hours.”, shown under a heading “Unlock Shift Hours”. A branch can therefore be prevented from opening by the length of its own shift, which is not a failure anyone would go looking for.

Menus carry hours of their own, separately from the branch. The portal has an “Open 24 Hours” switch for a menu, described as “If you make this menu opens 24 hours, that’s mean will be always available with restaurant time opens.” The implication of an always available option is that the default is not always available, so a restaurant can be open while the menu that holds its products is outside its own window. A chain seeing one branch absent at particular hours should check the menu schedule before it checks anything else.

Can a single item make a whole Ninja listing look wrong?

The portal treats availability as a first class thing, which suggests it matters. There is a “Mark Out Of Stock” action explained as “Mark unaviable items as out of stock”, the state “Out Of Stock”, a matching “Mark Available”, and a reporting view called “Availability Graph”. A platform that ships a graph of availability is measuring availability over time, not just at this moment.

The order screen closes the loop and shows the cost. Ninja’s cancellation reasons include “Product not available!” alongside “Too busy!” and “The restaurant is closed”, and cancelling carries a warning that “Please note that this may result in a cancellation fee. Do you wish to continue?” So an item left marked as sold out is not a neutral state. It produces cancellations, cancellations are attributed to the restaurant, and there is a fee attached, which is a stronger incentive to keep the catalogue honest than most platforms create.

Why is an integrated Ninja menu a visibility problem too?

Because the portal stops being usable on it. Where a menu arrives through an integration, Ninja’s interface refuses edits at every level, with “Integrated menus can’t be edited”, “Integrated categories can’t be edited”, “Integrated products can’t be edited” and “Integrated toppings can’t be edited”, and it refuses selection in the picker with “can’t select an integrated item”. The menu information panel labels such a menu “External”.

We did not find a string that says whether availability toggles survive that lock, so treat the boundary as unknown rather than assuming the worst. What is certain is narrower and still serious. On an integrated menu the person in the branch cannot correct the catalogue in the portal, and the portal is where the availability tools live, so the loop between noticing a problem and fixing it now runs through whichever system owns the menu. That is a longer loop, and every hour of it is an hour a customer may be seeing something wrong.

What does Ninja’s approval queue mean for a visibility investigation?

That almost nothing in the portal is immediate, so timing has to be measured rather than assumed. Creating an object returns “Request has been created! and it will reviewed by admin shortly.”, changing one returns “Change requested! and it will reviewed by admin shortly.”, a variant edit returns “Product Variant update requested successfully”, and a location change returns “Map update requested successfully!”. Seasonal hours are explicit that the system “will activate them after approval”.

The consequence for a chain is that the usual first move, change something and see what happens, does not work here. A branch fix submitted on Monday may not be live on Monday, and the portal offers no promised turnaround for any of these requests. Any conclusion about whether a change improved visibility has to be dated against when the storefront actually changed, not against when the request went in.

How should a Saudi chain measure Ninja visibility?

From outside the portal, because the portal has no view of it. There is no ranking report, no impressions figure and no position history in the interface, and the one preview it does offer shows a single card rather than the list that card sits in. Ninja’s own portal country list covers Bahrain, Kuwait, Qatar and Saudi Arabia, so a Gulf brand may need this reading in more than one market.

The method that fits is the plain one. Establish presence city by city from real customer addresses, record it with a date and an hour, and read it again after any approved change so the effect can be attributed. Because Ninja gives a restaurant an approval queue instead of a ranking setting, the only measurable thing is what a customer is actually shown, which is what Kitchain (kitchain.co) records from the customer side. Background on Ninja itself, and the rest of what we track there, is at kitchain.co/aggregators/ninja/.