Seller guide / Mirakl
Mirakl repricing: what sellers need to verify before automating
Mirakl provides a marketplace platform, not one universal seller workflow. Each operator decides the channels, Offer fields, pricing controls and competitive data it exposes. A safe repricing setup starts by validating the exact operator rather than assuming that one connector works everywhere.
See Mirakl repricingNeed the product workflow first? Review the Mirakl repricer page for supported capabilities and limits.
Why “Mirakl repricer” is not a single integration
Mirakl Marketplace includes seller APIs for Offers, pricing and asynchronous imports. Operators configure the marketplace around their own commercial model, so two Mirakl-powered sites can expose different fields, channels and permissions.
Before enabling automation, identify the operator, country, shop ID, channel codes, Offer identifiers and authorization scope. If competitive data is not available for that operator, the repricer must not invent it.
The data a repricing loop needs
A useful loop needs the current Offer, a valid pricing rule, seller-set boundaries and a market signal that is genuinely available. The Offer API can carry shop and channel context, while operator-specific endpoints determine what can be read or changed.
Price synchronisation and repricing are different. Synchronisation copies a known value. Repricing observes a permitted market signal, calculates a bounded target, submits it and verifies the result.
A safe Mirakl workflow
Start with a small set of exact Offers. Confirm identifiers and current values, add minimum and maximum prices, then run the marketplace-specific decision rule. Submit only eligible changes through the supported Offer update path.
Mirakl imports are asynchronous. Preserve the import identifier, poll its status and review line-level errors. A request that was uploaded successfully can still contain rejected items.
Channel pricing and common failure modes
Some operators use channel-specific prices. An update without the correct channel context can be irrelevant or wrong, even when the SKU is valid. Rate limits, inactive Offers, invalid ranges and operator-side validation can also stop an action.
The operational history should distinguish calculated, protected, submitted, processing, confirmed and failed. These states make it possible to diagnose the first broken stage without guessing.
When Autopricy is a fit
Autopricy supports selected Mirakl-derived operators after checking their actual API and Offer model. It is a fit when the operator exposes the inputs and actions required for bounded price automation. It is not a claim of compatibility with every Mirakl marketplace.
For a new operator, begin with one store and a controlled SKU sample. Expand only after identifiers, import feedback and later platform values agree.
Primary sources
Mirakl repricing FAQ
Does one Mirakl integration work for every operator?
No. Operators can differ in fields, channels, permissions, rate limits and competitive data. Support must be assessed per operator.
Is an accepted import a confirmed price change?
No. Keep the import ID, check processing status and review item errors before treating the update as complete.
Can a rule update channel-specific prices?
Only when the operator exposes that channel and the integration preserves the correct channel context.
Does Autopricy guarantee the winning Offer?
No. It controls eligible price actions; placement may also depend on delivery, availability, seller performance and operator rules.
Related resources
Continue from guide to implementation
Test the workflow on a real store
Start with one supported store, a controlled product scope and visible platform results.