Preparing your catalogue for Amazon, Cdiscount and Fnac

You want to set up listings on Amazon, Cdiscount and Fnac before the peak season, without having to re-enter the same catalogue three times. The difficulty is almost never the technical connection: that can be sorted out with a connector. The problem lies with your data, because each marketplace imposes its own mandatory attributes per category, its own vocabulary and its own validation checks. This article focuses on preparing the catalogue in advance: what is common to all three, what differs, and how to model it once to distribute it everywhere.

The real hurdle: three grammars, not three pipelines

Connecting a feed takes a few days. Getting several thousand product listings accepted by three operators who don’t all ask for the same things takes weeks if you tackle it file by file. The reason is structural: on these platforms, the data model isn’t global; it’s defined by category. A drill and a pair of trainers don’t require the same attributes or the same lists of values.

You therefore come up against three successive hurdles:

• Taxonomy— your internal tree structure must be aligned with that of each marketplace. It is this alignment that determines which attributes become mandatory. Until this is done, you do not know what you are missing.
• Vocabulary— a free-form value entered into your ERP (“midnight blue”, “brushed stainless steel”) must match a closed list of values on the marketplace side. Unrecognised values are rejected or silently ignored.
• Input validation— ID, image format, title length : checks are carried out at the time of integration, not afterwards. A rejected batch means you have to correct it and resubmit it.

The common foundation: what no marketplace will tolerate

Before looking at the specifics of each one, eight key areas must be in order in your product database. These are the ones that cause the majority of issues, across all channels.

• A unique and stable identifier— your SKU, which is immutable, never reallocated, and identical across all channels. This is the key that links an order, stock levels and a product listing.
• A valid barcode— a GTIN/EAN with a correct check digit that actually corresponds to the product being sold. This is also the key to linking to the marketplaces’ existing catalogues: a correct EAN prevents you from recreating a product listing that already exists. This topic is covered in detail in our article on the automatic validation of barcodes.
• The brand name, standardised— a single spelling per brand. “BOSCH” and “Bosch Professional” are considered two different brands for the purposes of matching.
• The manufacturer’s part number— the MPN. Along with the brand, this is the second identifier used when the barcode alone is insufficient.
• A reliable internal category— each part number linked to a unique family. Without this, no mapping to external taxonomies can be automated.
• A structured title— brand, range or model and distinctive feature, in separate fields. Composed of identified fields, it is re-formatted to suit each channel’s requirements; as free-form text, it cannot be re-formatted.
• Compliant images— a main image with a white background, in high definition, without a logo or watermark, plus secondary visuals. The minimum requirements vary by platform, but 1,600 pixels on the longest side satisfies everyone.
• Shipping weight and dimensions— packaged parcel, not the product on its own. These determine the displayed delivery charges and eligibility for certain delivery methods, and this is the section most often missing from supplier exports.

What differs from one platform to another

Amazon, Fnac-Darty and Cdiscount are based on three distinct technologies, which affects how you connect to them and the format of the data required.

Amazon: one data model per product type

Amazon does not publish a single list of mandatory attributes. It exposes, via the SP-API, a JSON schema for product_type: the Product Type Definitions API returns for each type the expected attributes, their formats and their constraints. These requirements are dynamic— filling in one attribute may make others mandatory. This is the task automated by the module described in our article on AmazonSP-API and Code2ASIN.

Two points warrant particular attention. Firstly, the parent-child hierarchy: variants (size, colour, capacity) are declared as children attached to a non-purchasable parent, with a variation axis (variation_theme). If your product database does not already distinguish the model from its variants, you will not be able to generate this structure correctly. Next, the title: since January 2025, Amazon has been applying a stricter policy to all categories — a limit of 200 characters including spaces (lower in certain clothing categories), a ban on repeating the same word more than twice , and special characters prohibited except in brand names. A title concatenated from fields can be brought into compliance in a single step; a free-form title must be corrected reference by reference.

As for visuals, the main image must have a pure white background (RGB 255, 255, 255), with the product occupying at least 85 per cent of the frame, in JPEG, PNG, GIF or TIFF format. The minimum size is 500 pixels on the longest side, but 1,000 pixels are required to enable zooming and 1,600 for optimal display.

Fnac and Darty: the Mirakl approach – separate products and offers

The Fnac and Darty marketplaces are powered by Mirakl technology. A useful consequence of this is that the same integration provides access to a broad ecosystem of retailers, a topic covered in detail in our article on the Mirakl connector and the 400 marketplaces accessible via a single connection.

The key feature to note is the separation between product and offer. The product contains the descriptive content: title, brand, description, category, technical specifications, images. The offer contains the commercial terms: your sku, price, quantity, condition of the item (state) and the logistics class (logistic-class). The two are linked by a pair product-id / product-id-type, the latter specifying the nature of the identifier used for the link.

You must therefore be able to determine, based on the reference: should I create the product record, or should I post an offer on an existing record? Fnac-Darty operates using a repository of standardised product records identified by EAN or ISBN. If the product is listed there, only the offer is required; otherwise, you must first submit the product with the attributes and lists of values defined by the operator. Your PIM must generate both data feeds and know which one to trigger.

Cdiscount: the transition to the Octopia REST API

Cdiscount operates its marketplace using its own technology, provided by its subsidiary Octopia. The old SOAP API was phased out in 2025 in favour of a REST API : if your integration is several years old, check this before the peak season.

In terms of data, two rules govern the preparation process.EAN-based mapping is possible: if another seller has already created the product listing, you do not need to provide the full product content. However, category mapping remains mandatory in all cases, including when linking via EAN — many sellers assume the opposite and get stuck at this stage. It should also be noted that products with variants require a step to add them to the variant repository, even when the product already exists.

A single master file, sets of attributes per channel

The temptation, when opening a third channel, is to create a third master file. This is where discrepancies begin: six months later, three versions of the same description coexist. The alternative is based on three principles.

• A single canonical repository— one value, one source. The dispatch weight for a product reference is a single piece of data, not three. Any inconsistency is resolved once, at source, and propagated everywhere.
• Sets of attributes by product family— you do not model a generic catalogue, but product families, each with their own relevant attributes. It is this breakdown that dictates, family by family, what content to feed into each channel.
• Output transformation— the channel is a view, not a storage repository. The Amazon title, the Fnac title and the Cdiscount title are three projections calculated from the same source fields. The same applies to categories, units and lists of values.

Consequence: mappings are data in their own right, to be stored, versioned and maintained. Taxonomies evolve, and an obsolete mapping causes mass rejections at the worst possible moment.

Pre-publication checks: only publish what will pass

With the current model, the aim is to ensure that no data issues are discovered on the marketplace side. Three mechanisms are sufficient.

• Make attributes mandatory by product family and by channel— the same attribute may be optional for one channel and mandatory for another. The rule is defined once and also applies to product listings created in future.
• Measuring completeness by channel— an overall score is of no use when making decisions. What matters is knowing that a product listing is ready for Cdiscount but not for Amazon, due to the absence of two attributes required by its product type.
• Block the publication of incomplete product listings— those that do not meet the channel’s rules remain on hold, with a list of missing fields.

As the peak season approaches, it’s better to publish 800 compliant product listings than to submit 2,000 listings, some of which will be rejected.

After publication: rejections, performance, pricing and stock levels

Going live is not the end of the job. Three loops run continuously.

• Monitoring rejections— each platform returns an integration status for each line item. This feedback must be fed back into the PIM, linked to the relevant product listing, rather than remaining in a separate back-office system.
• Seller performance indicators— cancellation rates, dispatch delays, response times, disputes. Specific to each operator, they determine your visibility, and part of this is decided upstream: an incorrectly set lead time or incorrect dimensions automatically lead to delays and returns.
• Updating prices and stock levels— the most frequent data flow, and it must be decoupled from the content: stock levels change several times a day, whilst a description changes a few times a year. On Mirakl, this separation is built-in, as the offer is a separate entity from the product; on Amazon, it is handled via the listing operations of the SP-API.

Frequently asked questions

Should I create new product listings or link to existing ones?

Link to existing ones whenever possible: on Fnac-Darty as well as on Cdiscount, linking via EAN reduces the time taken to list products and the volume of data required. Creating new listings should be reserved for items that you are listing for the first time.

How long does it take to prepare a catalogue for three marketplaces?

It depends on the initial state of the data, not the number of channels. If the barcodes are valid, the brands standardised and the product families consistent, adding a channel simply involves mapping categories and value lists. Otherwise, it is the overhaul of the foundation data that dictates the timeline — and this only needs to be done once.

Is a connector sufficient, or is a PIM required?

A connector transports data; it does not generate it. It will faithfully send Amazon a catalogue lacking shipping dimensions, and Amazon will reject it. The PIM is used to build the reference database, to manage attribute sets by product family, to store mappings and to block items that are not ready. The two are complementary : Pixee PIM has 15 native e-commerce and marketplace connectors, including Amazon SP-API and Mirakl, the latter providing access to around 400 marketplaces via a single connection.