Why marketplace listings get rejected for data, not quality
A listing can be well written, well photographed and correctly priced and still be rejected. Almost always the cause is structured data the marketplace requires and the submission did not carry. This explains the three classes of requirement and how to find your gaps before a rejection email does.
This guide covers the principles, which are stable. Per-marketplace field names and requirements change regularly — check the current documentation for the channel you are listing on before treating any specific field as authoritative.
Three things marketplaces check, in order
First, does the item have an identifier the marketplace recognises — a GTIN, UPC, EAN or ISBN, or an approved exemption. Second, does it sit in a category the marketplace can map, using that marketplace’s own taxonomy rather than yours. Third, does it carry every attribute that category marks required. A failure at any stage reads the same from outside: rejected.
Why required attributes vary by category, not by marketplace
Requirements attach to the category, not the channel. Two items on the same marketplace can have very different mandatory field sets — a ring needs metal and stone data, a monitor needs panel and resolution data. This is why a bulk upload that worked for one range fails for the next, and why "it worked last time" is not evidence the data is complete.
Identifiers are the most common single blocker
Most categories require a product identifier. Where an item genuinely has none — handmade, vintage, a bundle you assembled — marketplaces provide an exemption path, and using it is legitimate. What is not legitimate is inventing an identifier to clear validation. A fabricated GTIN can collide with a real product, attach your listing to someone else’s catalogue entry, and is a suspension risk.
Units and formats fail quietly
Weight in grams where the marketplace expects pounds, dimensions in centimetres where it expects inches, a date in the wrong order. These usually pass validation and produce wrong shipping quotes or wrong filters, so the damage appears as margin loss or poor visibility rather than as an error.
See the gap before you submit
The practical fix is to make missing data visible at draft time rather than at submission. Map your source columns to each marketplace’s fields, resolve what can be resolved automatically, and pin what cannot at the top of the draft as work to do. MergeKart holds publish until those are cleared, which is the same discipline applied automatically.