A marketplace listing rejected on submission is almost never a copywriting problem. It is an empty field, a value the channel does not recognise, or a category mapped to the wrong node. The causes are finite, they are published, and they are all fixable in your PIM before the feed leaves the building. Below is the catalogue, channel by channel, with the data fix for each.
Four causes, not twenty
Every rejection we have met on Amazon, eBay and Mirakl marketplaces falls into one of four buckets.
A required field is empty. The channel holds a required attribute list per category, and one of yours is blank.
A value is not on the channel’s list. You sent “Stainless Steel” where the channel accepts “Stainless steel” from a fixed enumeration.
The category is wrong. You mapped to a node that carries a different required attribute set, or to a branch node that accepts no offers at all.
The identifier or the media fails a format rule. A thirteen character EAN with a bad check digit. An image below the minimum pixel size.
That is the whole problem. It looks like twenty problems because each channel names the same four failures differently, and because the requirements sit in four different places. Assemble them once and the work becomes ordinary product data governance rather than a weekly firefight.
Amazon: rejected before the listing ever exists
Amazon validates a submission against a JSON schema for the product type you declared. Its Product Type Definitions API publishes those schemas. Amazon’s own wording is that they describe the attribute and data requirements for items in its catalogue. Submit through the Listings Items API and you get one of two statuses back. ACCEPTED means initial validation passed. INVALID means it did not, and the response names the issues.
Amazon’s listings workflow guidance tells developers to validate before submitting, using JSON Schema validation utilities. The stated aim is to confirm that required attributes are present, that values are valid, and that conditional rules are met. That instruction is written for integrators. It is really a product data instruction. The schema is the specification, and your PIM should be able to answer it.
| Rejection reason | What Amazon does | The data fix |
|---|---|---|
| Required attribute missing for the product type | Returns INVALID and names the attribute in the response. | Hold the Amazon product type on the SKU and validate against its schema before export. |
| Value outside the schema enumeration | Returns INVALID and names the offending value. | Map your list of values to Amazon’s enumeration once, in the PIM, not per feed. |
| No GTIN and no exemption on file | Blocks creation of the listing. | License the GTIN through GS1, or apply for and record the exemption. |
| Browse node too general | Product sits under a node with different required attributes. | Treat the leaf node as a governed attribute on the SKU. |
| Title over the category limit | Title is flagged and rewritten. | Generate titles from attributes with a length rule per category. |
| Bullet points with emojis or refund guarantees | Content is removed and regenerated by Amazon. | Strip the characters at generation, not after the rejection. |
| Main image below the minimum pixel size | Image is rejected and the listing shows without it. | Record pixel dimensions as an attribute and gate the export on it. |
The GTIN exemption is a data record, not a favour
Amazon’s published guide on applying for a GTIN exemption sets out the evidence it wants. You supply between two and nine real world photographs of the product and its packaging, showing all sides. Any branding has to be permanently affixed to the product. The guide states that “products should not have a GS1-approved barcode available on the product or packaging”. Approval arrives by email, and the guide says to expect it within 48 hours.
The mistake we see is treating the exemption as a one off task done by whoever was listing that week. It is a fact about the SKU. Record it, record the date, record which brand it covers. Six months later somebody relists the same product, cannot find the exemption, and the listing is rejected again.
Node before title
Amazon’s listing and content guide for its business and industrial categories tells sellers to “choose the most specific leaf node possible”. This matters, because the node determines the required attribute set. Pick a shallower node and you get a shorter required list. That feels easier, and it produces a listing nobody can filter to.
Titles are moving. Amazon’s seller communications describe a 200 character allowance. It is split between an Item name of 75 characters and Item highlights of 125 characters. Recommendations against non-compliant titles began in late July 2026, with Item highlights displaying from 10 August 2026. Older Amazon category guides give tighter limits, under 100 characters in one and under 80 in another. There is no single number. There is a number per category, and it belongs in your channel model.
eBay: blocked at the point of listing
eBay is the bluntest of the three. Its UK Seller Centre guidance on item specifics states that “new or revised listings that don’t include required item specifics will be blocked”. Not downranked. Blocked.
The requirements are machine readable. eBay’s Taxonomy API returns an aspect constraint per category with a set of fields that map cleanly onto a PIM attribute model. The aspectRequired field marks an aspect as required for that category. The aspectMode field states whether the seller supplies free text or picks from available options. There is an aspectMaxLength for the value. There is an aspectEnabledForVariations flag showing which aspects can identify variations.
There is also an expectedRequiredByDate field, described as “the expected date after which the aspect will be required”. That field is the most useful one in the whole response and almost nobody reads it. It tells you which of today’s optional aspects becomes tomorrow’s blocked listing.
| Rejection reason | What eBay does | The data fix |
|---|---|---|
| Required item specific missing | Blocks the new or revised listing outright. | Pull the required aspect list per category and treat it as a schema. |
| Value not in the allowed selection | Rejects the value where the aspect mode is selection only. | Map your values to eBay’s allowed set and store the mapping. |
| Value over the maximum length | Rejects the value. | Hold a per aspect length rule and enforce it at generation. |
| Aspect becomes required on a stated date | Blocks listings from that date onward. | Read the expected required by date field and fill the gap early. |
| GPSR information missing for EU or Northern Ireland | Listing is not visible or purchasable in those markets. | Model manufacturer contact, responsible person and warnings as attributes. |
GPSR fields are attributes
The EU General Product Safety Regulation applies from 13 December 2024. The UK government’s own business guidance confirms the date. It requires a responsible economic operator established in the EU or Northern Ireland. eBay’s UK Seller Centre page on the regulation lists what sellers must provide.
- The manufacturer’s name and contact information.
- An EU based responsible person, with name and contact details, where the manufacturer sits outside the EU.
- The model number, pictures and type.
- Warnings and safety information in the local language.
- CE marking where the category calls for it.
eBay is explicit about the consequence. Listings without it “may not be visible or purchasable to buyers in the EU and Northern Ireland”. Visibility is restored when the information is provided. eBay also notes the regulation does not apply to sales to UK buyers, except Northern Ireland.
Every one of those items is an attribute. Manufacturer contact belongs on the brand or supplier record. Responsible person belongs there too. Warnings belong on the product, translated, versioned, and with an owner. Teams that put them in a free text field at listing time end up doing it again for every channel and every language. We treat regulatory fields exactly like commercial ones in the attribute model, because that is what they are.
B and Q: rejected twice
B and Q launched its marketplace at diy.com on 10 March 2022, running on Mirakl. That is Kingfisher’s own announcement. It has grown fast. Kingfisher’s 2025/26 annual report puts group marketplace GMV at £518m, up 58% year on year. It reports 3.7m products available at diy.com alone, with marketplaces accounting for 15% of total ecommerce sales. If you sell into DIY, trade or garden categories, this is a real channel now. It is worth understanding how it says no.
Mirakl fails your data at two separate points, and the difference matters because the remedy differs.
Integration failures happen when the file is read. The product is never created, and the row appears in what Mirakl’s API documentation calls the “non-integrated products report”. You fix the file and reimport.
Transformation failures happen after the product exists but before an offer can be published. Mirakl’s product import statuses include TRANSFORMATION_WAITING, TRANSFORMATION_RUNNING and TRANSFORMATION_FAILED alongside the plain WAITING, RUNNING, SENT, COMPLETE, CANCELLED and FAILED. A product sitting in transformation failure looks like it uploaded fine. It is not sellable.
| Rejection reason | Where it fails | The data fix |
|---|---|---|
| Category not mapped, or mapped above leaf level | Integration, so the product is never created. | Maintain the map from your taxonomy to the operator hierarchy as data. |
| Required attribute empty for that hierarchy | Transformation, so the product exists but no offer does. | Read the requirement level per attribute per hierarchy and validate first. |
| Value outside the operator value list | Transformation, silently, on that attribute. | Store the operator value list mapping next to your own list of values. |
| Product identifier in the wrong format | Integration, on the whole row. | Validate length and check digit before export, not after rejection. |
| Variation axis attribute missing | Transformation, and the variants collapse into singletons. | Flag which attributes are variation axes in your own model. |
Mirakl publishes the attribute configuration through its API, and it reads like a PIM schema because it is one. Each attribute carries a requirement_level of OPTIONAL, REQUIRED, RECOMMENDED or DISABLED. Each carries a variant flag, which marks whether the attribute is a variation axis. Each can carry a values_list code pointing to the list of authorised values. Each carries a hierarchy_code, the category the attribute belongs to. An empty hierarchy code means the attribute is shared across all categories.
Read that list again and you have the specification for a channel attribute set inside your own PIM. Required or not. Variant axis or not. Constrained list or free value. Scoped to a category or global. Any PIM worth its licence fee can hold all four. Most implementations we inherit hold none of them, which is why the operator’s list of values lives in a spreadsheet on someone’s laptop.
Screwfix and the retailers that publish nothing
Here is where we have to be straight with you. Screwfix does not operate a public third party marketplace in the way B and Q does, and it publishes no public product data specification. Neither do most trade retailers. If you supply them, the requirement arrives as a new line form from a buyer. Or as a template attached to an email. Or as a portal built by their ecommerce team, with rules nobody has written down.
The failure mode is different and worse. On Amazon you get an INVALID response naming the field. From a buying team you get silence, then a chased phone call, then a line that never goes live. There is no error report to work from.
Three things work in that situation, and we have done all three on building supplies and industrial accounts.
Reverse engineer the specification from the retailer’s own site. Their filters are their required attributes. Look at a DIY and tools category page. If a shopper can filter by drive type, thread size and finish, those three are mandatory whatever the form says.
Treat the completed new line form as a schema artefact, not as an email. Every retailer form you fill in is a channel attribute set. Capture it, version it, and put it in the PIM so the next person does not start from a blank sheet.
Ask for the rejection reason in writing, once, and keep it. Over a year that correspondence becomes the specification the retailer never published. We build exactly this record during supplier data onboarding, in the opposite direction, and it works the same way facing outward.
The root cause behind every rejected marketplace listing
Four channels, four vocabularies, one problem. Each channel holds a category specific required attribute set with constrained values. Your PIM holds one internal schema, designed for your own website. Nobody owns the mapping between them.
So the mapping lives in the feed tool, or in the middleware, or in the head of the person who does the listings. It is invisible to the merchandisers who create products. It is invisible to the buyers who onboard suppliers. And it only surfaces as an error, weeks later, at the point of sale rather than the point of creation.
That is why the same SKU gets rejected on three channels for three apparently unrelated reasons. It was never enriched against any of their schemas. It was enriched against yours.
How to stop marketplace listings being rejected
Model each channel as an attribute set, not as a feed mapping. Amazon’s product type schema, eBay’s category aspects and Mirakl’s hierarchy attributes are all the same object. Hold them in the PIM, scoped to your taxonomy nodes, with required flags and constrained values.
Map lists of values once and store the mapping. “Stainless steel” to Amazon’s enumeration, to eBay’s selection list, to the operator’s value list. Do it in the data layer, never in the export template, because the export template is invisible to everyone who is not an integrator.
Validate before you send. Every one of the four channels above publishes machine readable requirements. There is no reason for a channel to be the first system that tells you a required field is empty.
Feed rejection reports back into the model. A rejection is a specification you did not have. Capture it as a rule, not as a ticket.
Make completeness visible to the people who create data. A merchandiser adding a product should see that it is 100% complete for your website and 62% complete for the marketplace channel. That single change does more for marketplace readiness than any amount of feed tooling.
Cover the regulatory fields as first class attributes. GPSR contacts, responsible person, warnings, CE marking. They will be required on more channels next year than this year.
Key takeaways
- A rejected listing is a schema failure, not a content failure. Empty required field, unrecognised value, wrong category, or bad identifier format.
- Amazon validates against a published JSON schema per product type and returns INVALID with the offending attribute named.
- eBay blocks new and revised listings that lack required item specifics, and publishes the date an aspect becomes required.
- Mirakl marketplaces such as B and Q fail data twice, once on integration and once on transformation, and the second failure is silent.
- Trade retailers that publish no specification still have one. Their site filters and their new line forms are it.
- The durable fix is to hold each channel’s required attribute set inside the PIM and validate before export.
Rejections are the visible symptom. The underlying issue is an attribute model that was never designed to serve more than one channel. That same model is behind thin filters, weak on-site search and stalled product content enrichment. Fixing it fixes all three. Sequencing matters, which is why we start with taxonomy and attribution rather than with the feed.
Rejections outrunning your team? Book a thirty minute call. We will read your rejection reports and tell you which three attributes are causing most of them.