How Ajio feeds work

If you take one thing from this help centre, take this. Most of the effort wasted on Ajio catalogue uploads comes from a single misunderstanding, and it is an entirely reasonable misunderstanding to have.

An upload is not a submission. It is a feed.

When you upload a catalogue workbook, Ajio creates a feed with its own UUID. That feed then claims two things about every row in it:

  • the style codes
  • the barcodes (EANs)

It claims them separately, and it holds them whether the row passed or failed, until the row is released or soft-deleted.

This is the part that catches people. You upload 100 rows, 60 go live and 40 are rejected. Intuitively the 40 failures are "not listed", so they ought to be free to submit again. They are not. The feed still owns them.

What happens when you re-upload

You fix the 40 rows, build a clean file, upload it. Ajio creates a second feed — and that second feed immediately collides with the first:

Cannot process this ean, it is present in different feed --> id: <the-first-feed-uuid>

So you fix something else and upload again. Third feed. Third collision.

On one catalogue we audited, 11 of 23 feeds existed for no other reason than this. Each rejection prompted a fresh upload, which collided, which prompted another. None of the underlying product data was wrong by then. The corrections were fine. They were simply being delivered to the wrong place.

The correct repair loop

  1. Open the feed in Upload History.
  2. Download its rejection file from the Rejected link.
  3. Edit that file — correct the values in place.
  4. Re-upload that same file.

The rejection workbook carries a feedId in its Seller Information Sheet. Ajio reads that field and amends the existing feed rather than opening a new one. You can watch the counts move on the existing row in Upload History instead of a new row appearing.

Build from a blank portal template instead, and you have no feedId, so you are back in the collision loop.

Two rules that follow from this

Work oldest-first. The portal lists newest feeds first, which is exactly backwards. The earliest feed owns the products; later ones are collisions holding nothing. Fixing the newest feed cannot work no matter how clean the data is.

One file per feed per fix. If a feed has two faults on the same rows, correct both in one workbook. Upload two files and the second silently reverts the first. We watched a measurement correction get undone this way — a second file, prepared for a different field, overwrote the first fix on the same rows.

How to release SKUs from a feed

You do not need your Ajio SPOC to release rejected products from their owning feed.

  1. Download the owning feed's rejection file.
  2. Find every row belonging to the SKUs you want to release.
  3. Clear those SKU rows, leaving unrelated product rows unchanged.
  4. Re-upload the same rejection workbook under a new filename.

The workbook's feedId tells Ajio to amend the owning feed. Clearing the selected rows removes those products from that feed and releases their style codes and barcodes, so they can be submitted in a corrected fresh file.

Use this as an intentional release action. If you want the products to continue inside the current feed, correct their values instead of clearing the rows.

The two ways a rejected row becomes free

The rule "a rejected row still holds its barcode" is true only while the row is live in the feed. A row becomes free when either:

  • Ajio soft-deletes it automatically, or
  • you clear its SKU rows in the owning feed's rejection file and re-upload that file.

That is a genuinely different state, it is visible in your catalogue report, and it changes which repair route is available to you. It has its own page: Is my barcode free?

Diagnosing a catalogue that is already tangled

If you have inherited a mess of colliding feeds, resolve to the product, not to the feed. "Held by feed X" is plumbing, not a status. Follow the pointer:

  • Feed X succeeded → the product is already live. No action.
  • Feed X's own rejection file shows a genuine defect for that style → that is the real problem.
  • Feed X looks clean in the portal → the product is in flight, not blocked. Stop resubmitting.

Doing this on one stuck catalogue collapsed "blocked by another feed" from 29 styles to zero. Every one was already live or already moving.

A related trap: download the Success export too, not just the rejection files. A feed that succeeds outright never produces a rejection file, so rejection files can only ever prove what failed. A style's absence from them means nothing. On one account, pulling Success exports moved 70 styles from "no record anywhere" to confirmed live in a single pass.

Why Ajio works this way

Speculating, but it is consistent: the feed is the unit of processing and audit, so identity has to bind at upload rather than at approval. It makes sense from the platform's side. It is just unintuitive from the seller's, and nothing in the interface hints at it.

Next: Is my barcode free? · Cannot process this ean

Last verified against Ajio Self Serve on 31 August 2026. Ajio changes portal behaviour without notice — if something here no longer matches what you see, we would genuinely like to know.

HyndBrain lists apparel catalogues across seven marketplaces. Talk to us if yours is stuck.