Guides · ONDC Visibility
ONDC Product Not Showing? 6 Silent Reasons, With Fixes
Updated: August 2026 · 10 min read
✅ Straight answer: If your product is not showing on buyer apps, it is failing one of 6 silent gates: it is not in the published catalog at all, your delivery radius is too small, a statutory declaration is being left off, photos or attributes miss the bar, the buyer app has not crawled you yet, or a setting never reached the wire. None of them shows you an error. Below is what the software actually does at each gate — and how you check your own listing without asking anyone.
Every night, your shop is not “on the internet”. It is a file. A seller platform builds a catalog payload for your shop and hands it to buyer apps when they ask for it. Whether a product of yours is inside that file — and whether the buyer app keeps it after reading it — is decided by plain if conditions.
That is the hardest thing to accept about the ONDC Network: when your listing is blocked, nobody tells you. There is no rejection screen. A product can be missing from every buyer app while your dashboard looks perfectly green, because no gate in this chain sends a message back to you.
We run a Seller App in the ONDC Network, so we write the code on one side of that wire and read buyer-app behaviour on the other. Here are the 6 gates, in the order the system applies them, with the real rule at each one.
📊 The 6 silent gates between your product and the buyer
Gates 1–3 happen on your seller platform. Gates 4–6 happen inside the buyer app. None of them sends you an error.
1. Is your product even inside the catalog that gets published?
Start here, because this gate removes the product completely — not lower in results, not on page 3. It is simply absent from the file buyer apps read, so no amount of searching will find it.
In our catalog builder, an item is copied into the outgoing catalog only if it passes four conditions. Any seller platform will have its own version of this list; ours is:
The include-or-drop test, per item
- Approval status is approved — an item still pending review, or rejected, is not published.
- The availability toggle is on. One accidental tap on a switch takes a product off every buyer app that night.
- The item is not deleted (soft-deleted items stay in your database, never in the catalog).
- If you track stock for that item, quantity must be above 0. Stock 0 with tracking on = the item leaves the catalog entirely.
There is a related trap in how stock travels. On the ONDC Network, the quantity field in a catalog is a signal, not your real inventory: it goes out as 99 for “in stock” or 0 for “out of stock”. Your true stock number stays private with your platform. An item sitting at 0 is technically in the catalog, but most buyer apps will not surface an out-of-stock product in search results — so it looks identical to being invisible.
Check it yourself: Open your product list and read three columns on your weakest product: approval status, the availability switch, and stock. If approval is not “approved”, or the switch is grey, or stock is 0 — you found it, and no other gate matters until that is fixed.
2. Is your delivery radius quietly set to 5 km?
Every catalog that goes out carries a serviceability tag for your shop: a location, a category, and a value in kilometres. Buyer apps filter on that number before showing you to anyone. A buyer standing outside your circle will never see your shop, and neither of you will ever know.
The specific thing to check: what happens when a seller never sets a radius. In our builder the tag falls back to a default of 5 km when the shop has no radius of its own. That default is not a bug — it is a safe guess for a kirana that delivers on a scooter. But if you sell packaged goods that a delivery partner ships for you, a 5 km circle throws away the entire point of being online.
This one bit us early. A seller who wanted buyers across India was going out on the wire with a small local radius. Nothing was technically wrong, so nothing errored. The tag said one number, and every buyer app obeyed it. The night the radius was corrected, the storefront card appeared on a buyer app about 30 minutes after that app’s next catalog crawl — same products, same photos, only the circle changed.
Check it yourself: Find the delivery-radius setting in your dashboard and read the number out loud. Does it match who you actually want to sell to? If you deliver yourself, keep it honest and local. If a courier ships for you, ask your platform to confirm the radius value that is going out in the catalog — not just the value stored in the form.
3. Is one missing field deleting your whole label declaration?
This is the gate that catches the most sellers, and the rule behind it surprises everyone.
Indian law (the Legal Metrology rules for packaged goods) says every packaged product sold online must display declarations: manufacturer or packer name and address, net quantity, MRP, month and year of packing, and customer-care details. ONDC’s network policy backs this with a specific rule — Rule 2.3.8 — which allows a buyer app to hide any listing whose statutory information is missing.
Now the mechanism. An honest seller platform will not invent this data. Ours checks three fields together, and the check is an AND, not a score:
📊 How one blank field removes the entire declaration
Maker name
filled ✓
Maker address
filled ✓
Packing month/year
blank ✗
Whole block omitted
Item still ships — with no declaration at all
A partial declaration is worse than none, so the wire sends none. Buyer apps that enforce Legal Metrology are then allowed to hide the item.
Read that again, because it is the whole trap: the product does not get rejected. It goes out looking fine, minus the block called @ondc/org/statutory_reqs_packaged_commodities. Strict buyer apps drop it. Lenient ones keep it. Your dashboard shows the same green either way.
Food items carry a second block on top of that one. For the prepackaged-food declaration our rule is an OR: any one of a brand-owner, importer, or other FSSAI licence number satisfies it. Nutrition text is either the real text off your label or the honest line “Refer product label” — never an invented figure. Miss the licence entirely and the food block is omitted the same silent way.
📷 Where these fields live on the product form
Manufacturer name
Sharma Foods
Manufacturer address
Plot 14, MIDC, Dhule 424001
Manufacturing date (month/year)
06 / 2026
Veg / Non-veg
Veg
FSSAI licence (14 digits) — food only
Required for food
Check it yourself: Pick any packaged product and confirm five things exist on it: maker/packer name, full address, net quantity, MRP, and month + year of packing. Then ask your platform one direct question — “which of my products are going out without the statutory block, and which field is missing?” Their software can answer that in seconds, because it is the same test it runs before publishing. On Kaarobari the product form itself blocks the save until those fields are filled, so the gap is caught before the item ever ships. Food sellers can see the full document list on our seller documents page.
4. Do your photos and attributes clear the buyer app’s bar?
Gates 1–3 happen before publishing. This one happens inside the buyer app, using listing-quality rules from ONDC’s seller guidelines. Products that miss the mandatory bar are not shown lower. They are dropped.
The rules that catch most small sellers:
| Rule | What buyer apps expect |
|---|---|
| Photos | At least 4 images, including a clear front AND back of the pack |
| Food products | The FSSAI licence number must be readable on the product image itself |
| Products under quality-control orders (electronics, toys, some appliances) | The BIS/ISI mark visible as an image |
| Attributes | Every “mandatory” attribute for your category filled — a missing one can drop the whole product |
One useful right you have: ONDC network policy (rule 2.3.15) lets a seller platform demand each buyer app’s mandatory-attribute list. If one specific app is not showing your products while others do, your Seller App can ask that app, in writing, what exactly it requires. Ask your platform to use that right — it turns a guess into a list.
Check it yourself: Count the images on your weakest listing. If it is one blurry phone photo of the front, that listing is probably invisible on the stricter apps whatever your dashboard says. Shoot the back of the pack too — that is the photo that carries the licence number and the declarations.
5. Has the buyer app even crawled your catalog yet?
This gate is about patience, and it is the most common false alarm.
Buyer apps do not watch your catalog live. They crawl seller catalogs on their own schedule, and in our delivery logs those crawls cluster late at night, roughly between 1 AM and 3 AM. On one typical night we counted 455 catalog copies handed to buyer apps, most inside that window. After an app crawls you, your products typically appear on its storefront within 4 to 30 minutes.
There is also a rule buried in the network contract that surprises everyone: the small “incremental” updates that flow during the day cannot introduce a brand-new shop. A buyer app must do a full crawl before your shop exists for it at all. So:
- New shop, listed today at 4 PM, not visible at 6 PM? Normal. Wait for tonight’s crawl window. Check tomorrow morning.
- New product added to an already-visible shop? Usually faster, but the same night-crawl logic can apply per app.
- Still nothing after 2–3 nights? Now it is not the clock. Go back to gates 1, 2, 3 — or ask your platform to escalate to the buyer app.
📊 When buyer apps actually pick up your catalog
Afternoon
You add products
Nothing visible yet — normal
1 AM – 3 AM
Buyer apps crawl catalogs
455 copies in one night
Morning
Products appear
4–30 min after each crawl
Check it yourself: Write the date and time you finished your listing on a piece of paper. Judge visibility only after two full nights have passed. Before that, you are debugging a clock.
6. Do your settings actually reach the wire?
Here is a check almost no seller does: compare what a buyer app says about your shop with what your settings say. A setting can exist on a dashboard and still never reach the catalog buyer apps read — or reach it rewritten.
Three examples straight out of how catalogs are built, so you know what to look for:
| What goes out | The rule behind it | How it burns a seller |
|---|---|---|
| Return window | An item is returnable only if BOTH the item’s own flag and the shop-level return policy allow it. If either says no, the window goes out as P0D — zero days. | One shop-level switch silently rewrites the return promise on every product you own. |
| Cash on delivery | COD is advertised from a platform-level setting, not per product. | A storefront can offer COD that then fails at the final confirmation step — the buyer’s order dies at the last screen. |
| Shop timings | Opening and closing time and working days travel as their own tag with the catalog. | Wrong hours make a live shop look closed to a buyer app at exactly the hours you sell most. |
Why does any of this hide listings? Because wrong promises create failed orders and buyer complaints, and buyer apps derank or drop sellers who cause them. An order that always dies at confirm looks, from the buyer app’s side, like a broken seller.
Check it yourself: Find your own shop on any buyer app (search your shop name or a product name). Read your own storefront card like a stranger would: returns text, cancellation text, COD, delivery promise, open/closed. If any line does not match what you set, report that exact line to your seller platform and ask them to verify it in the catalog payload. A good platform can check the actual payload in minutes.
The 6-gate check, in one table
Do these in order. Most invisibility cases end at gate 1, 2 or 5.
| # | Check | Where you look | Who fixes it |
|---|---|---|---|
| 1 | Approved + available switch ON + stock above 0 | Your product list, three columns | You, 1 minute |
| 2 | Delivery radius matches your real market (default is small) | Delivery settings — then confirm the value on the wire | You + your platform |
| 3 | Maker name, address, packing month/year on every packaged item; FSSAI on food | Each product's details form | You, per product |
| 4 | ≥4 photos incl. front + back; FSSAI readable in the image | Each product's images | You + a phone camera |
| 5 | Two full nights passed since listing (crawls run ~1–3 AM) | Calendar | Patience |
| 6 | Storefront text matches your settings (returns, COD, timings) | Your own shop, on a buyer app | Your platform verifies the payload |
Questions sellers ask us
My dashboard shows everything is fine. So the buyer app is cheating me?+−
Sahi sawaal, and usually no. In every case we have debugged, the buyer app was applying a written rule — radius, Rule 2.3.8, mandatory attributes — to data we had sent it. The rules simply act silently. Work the 6 gates first. Network policy (rule 2.3.3(k)) also requires buyer apps to show all valid results without discrimination, so once your data is clean, you have standing to escalate.
Why can't my platform just fill the packing date itself?+−
Because that date is a legal declaration about your goods, not a form field. Inventing one would put a false statutory claim on a live listing in your name. So an honest platform leaves the block off instead — which is exactly why a blank field turns into an invisible product. The fix has to come from you, once, per product.
I fixed my product today. When will it show?+−
Expect tonight's crawl window, roughly 1–3 AM, then 4 to 30 minutes after each app's crawl. Check in the morning, not in the next five minutes. If two nights pass with nothing, it was never the clock — go back to gates 1, 2 and 3.
How do I even see my own shop as a buyer?+−
Install any buyer app on the ONDC Network, set the delivery address inside your own delivery radius — this matters, because outside the radius you will not find yourself either — and search your shop or product name. Reading your own storefront once a month is the cheapest audit you will ever do.
Can Kaarobari check all 6 for my shop?+−
Yes. This checklist is built into how we onboard sellers on the ONDC Network: radius set with intent, statutory fields required before a product can save, and payload checks when something looks off. Costs stay simple — no monthly fee, no listing fee, 2% only on delivered orders. On a ₹1,000 order, ₹980 reaches you.
Stuck on any document? Our team gets it done on a call — no charge
We have a dedicated team that guides you step-by-step on a call and gets every document made — Udyam, GST enrolment, FSSAI, all of it. And not just documents: from signup to your shop going live on the ONDC Network to your first delivered order — support at every step, completely free. No fees, no agent costs.
Mon–Sat, 10am–7pm. Hindi and English both work.
Read next
Sources
- ONDC Network Policy, Chapter 2 — rules 2.3.3(k), 2.3.8, 2.3.15 (resources.ondc.org)
- ONDC Retail API contract — catalog item fields, including the packaged-commodities and prepackaged-food statutory blocks and the serviceability tag
- Legal Metrology (Packaged Commodities) Rules — declaration requirements for e-commerce
- ONDC seller onboarding guidelines — image and mandatory-attribute requirements
- Kaarobari catalog builder — the include-or-drop test, the statutory name-AND-address-AND-date rule, the default service radius, and the return/COD/timing fields described above are how our own Seller App builds catalogs (August 2026); catalog-delivery timings from our own request logs