Mirakl is one platform. Every marketplace built on it has its own catalog rules.
Operators running on Mirakl each define their own category tree, their own required attributes and their own value lists. A catalog mapped for one is not mapped for the next. Synaps classifies each product into every operator's taxonomy and fills the attributes that operator requires.
The problem
One integration, many catalog standards
Connecting technically to a Mirakl-based marketplace is the easy part. Meeting that specific operator's category and attribute requirements is where onboarding actually stalls.
Mapping is redone for every new operator
Each launch means reclassifying the catalog into a different tree and filling a different required-attribute set, which is why the second marketplace rarely goes live faster than the first.
Value lists are closed, not free text
Many required attributes accept only values from a defined list. A correct value in the wrong vocabulary is rejected exactly like a missing one.
Requirements change without notice
Operators revise their category trees and attribute sets over time, so a catalog that passed validation last quarter can start failing without anything changing on your side.
Everything you need
Per-operator classification
Each product is classified into each operator's own category tree, rather than into one generic taxonomy mapped approximately onto all of them.
Required-attribute resolution
Once the category is known, the attributes that category requires are known too — and sourced for every product in it.
Value-list conformance
Enriched values are matched to the operator's allowed list, so a colour or material lands in the vocabulary that operator accepts.
Unit and measurement normalisation
Dimensions and weights are normalised to the unit each operator expects, which removes a common and easily missed cause of rejection.
Market-specific localisation
Content is produced in the language of the operator's market, so a catalog can open a new country without a separate translation project.
Re-validation when rules change
Catalogs are rechecked against current requirements rather than against the requirements that applied at onboarding.
How it works
- 01
Read the operator's catalog rules
Synaps takes the target operator's category tree, required attributes and value lists as the specification to meet.
- 02
Classify the catalog into that tree
Every product is placed in the operator's own category, which determines exactly which attributes it needs.
- 03
Fill and conform the required attributes
Missing values are sourced, then matched to the operator's units and allowed value lists rather than submitted as free text.
- 04
Validate before submission
The mapped catalog is checked against the operator's requirements first, so failures surface before they become rejections.
How to map product attributes for Mirakl marketplaces
Mirakl is marketplace software, not a single marketplace. Each operator running on it defines its own category tree, its own required attributes and its own accepted values, so a catalog prepared for one operator is not prepared for another. Mapping product attributes for a Mirakl marketplace means classifying each product into that specific operator's taxonomy, then supplying the attributes that operator requires for that category, in the units and vocabularies it accepts. Synaps automates that per-operator mapping and validates the result before submission.
This is why the second marketplace often takes as long as the first. The technical connection is reusable; the catalog work is not. Sellers who expect to map once and distribute everywhere discover that the shared part of the effort is smaller than expected, and that most of the work is per-operator by construction.
The category assignment is the decision everything else depends on, because the category determines the required attribute set. Get it wrong and the product is either rejected or accepted into a category where buyers filtering on the attributes that matter will never see it. That second outcome is worse, because it looks like success: the product is live, and it simply does not sell.
Value conformance is the failure mode teams underestimate. Many required attributes are closed lists rather than free text, so a correct value expressed in your own vocabulary is rejected exactly like an empty field. The same applies to units: a dimension in millimetres submitted where centimetres are expected is a valid number and an invalid value.
Frequently asked questions
See your catalog mapped to a real operator's taxonomy
Send a sample and a target marketplace, and get back the classification and the attribute gaps.
Map a sample