Is my barcode free?

Ajio binds every barcode to the feed it was uploaded in. A rejected row still holds its barcode, so re-submitting it in a fresh upload normally fails with "present in different feed".

The barcode becomes free in two ways: Ajio soft-deletes the row automatically, or you release it yourself by clearing its rows in the owning feed's rejection file and re-uploading that file.

Where to look

Download your Catalogue Report from the portal. It has a column called Is SoftDeleted.

• DELETED → Ajio has removed that row from its feed. The barcode is released.
• blank → the row is still live in that feed. The barcode is held until you amend or release it.

That is the whole test.

What the difference is worth

We measured this across an entire account's upload history — every barcode that appeared in one feed and later in another:

A live row is refused every single time when submitted straight into a new feed. There were no exceptions in 143 attempts. Release it from the owning feed first.

A soft-deleted row goes through about 61% of the time. It is the only state in the measured data where a direct fresh-feed attempt had a chance without first releasing the row yourself.

The portal signal that confuses everyone

Here is where this gets genuinely misleading.

When Ajio soft-deletes the failing rows from a feed, that feed's Auto QC column shows a green tick and offers no rejection file to download. Nothing left in it is failing, because the failures were removed.

So you look at a feed you know contains broken products, and it appears to have passed. There is nothing to download, nothing to amend, and no explanation.

We spent a while concluding those feeds were blocked and unfixable. They were the opposite: the products had been released and were free to re-submit. "No rejection file available" usually means the rows were deleted, not that you are stuck.

What to do

If the rows are DELETED: you cannot amend the old feed, because there is nothing there to amend. Build a fresh file containing just those products, correct the original fault, and upload it as a new feed.

Two things to get right when you do:

• Build on a known-good file for that category — ideally one of your own recent uploads that Ajio accepted. Do not build on a downloaded rejection file; those carry extra columns and a feed ID, and Ajio rejects them as "Incorrect data in sheet".
• Make sure your seller ID survives whatever editing you do. See Seller is not authorized to upload other seller's sheet.

If the rows are live (blank): choose what you want to do:

• Keep them in the current feed: correct the values in the owning feed's rejection file and re-upload it.
• Move them to a fresh feed: download the owning feed's rejection file, clear every row for the SKUs you want to release, and re-upload that rejection file under a new filename. Once Ajio processes the change, submit the corrected products in a fresh file.

Releasing rows this way is self-serve. You do not need to contact your Ajio SPOC.

Worked example

A batch of 39 rows across four feeds had failed Auto QC on a style-code rule. All four feeds showed green ticks and offered no rejection file, so on the face of it there was nothing to work with.

Checking Is SoftDeleted showed all 39 rows were DELETED. We rebuilt them into four fresh files on a template that had recently been accepted, corrected the style codes, and uploaded.

All 39 cleared Auto QC. Not one duplicate error.

An open question

We do not know what makes Ajio soft-delete some failed rows and leave others live. It does not correlate cleanly with the failure reason in the data we have. If you have observed a pattern, we would like to hear it.

---

Related: How Ajio feeds work · Cannot process this ean

Last verified 31 August 2026.

HyndBrain untangles marketplace catalogues for apparel brands. Get in touch.