Not every Offer should run
The store, product identity, rule, boundaries and platform capability need to be valid first.
Feature / automatic repricing
Automatic repricing is a control loop, not a price-change button
Autopricy connects market inputs to explicit seller rules, price boundaries, marketplace submission and result tracking. Automation is enabled only where the platform and store provide the data and actions required for a safe loop.
Automatic repricing controls
Each stage can succeed or fail independently
A scheduled job or accepted API request proves only that stage. Reliable automation preserves the whole chain so operators can see where a price stopped.
The target needs an explainable reason
A price action comes from available market data and explicit logic—not an unsupported guess.
HTTP acceptance is not storefront proof
Submission, marketplace processing, read-back and persistence remain distinct.
Marketplace mechanics
The six stages of a trustworthy repricing run
| Eligibility | Confirm shop authority, exact Offer identity, valid rule and supported platform workflow. |
|---|---|
| Market input | Read the current Offer and only the competitor or winning data the platform exposes. |
| Decision | Calculate a target inside minimum and maximum boundaries. |
| Scheduling | Use locks and platform-aware pacing to avoid conflicting or excessive work. |
| Submission | Send the action through the marketplace-specific adapter. |
| Result | Record platform feedback or read-back and preserve the final status in history. |
Automatic does not mean uncontrolled
Autopricy’s core price decisions use explicit rules and seller-set boundaries. The system should stop or expose an exception when a required input is missing, a lock is held, a platform rejects the request or confirmation is unavailable.
Workflow
Move from observation to automation
Connect and synchronise
Verify exact store and Offer records before creating rules.
Configure boundaries
Set minimum, maximum and marketplace-appropriate strategy.
Run a limited scope
Observe calculated, protected and submitted states on a small product set.
Expand after confirmation
Scale only when later platform results and history match expectations.
Control example
Where an automated run should stop
Example: the scheduler starts and finds a valid Offer, but the competitor input is unavailable. The correct result is not a guessed target. The run should skip or record a clear state, leaving the last confirmed marketplace price unchanged.
Related resources
Continue with the relevant workflow
FAQ
Automatic repricing is a control loop, not a price-change button: common questions
Which marketplaces support automatic repricing?
Current public scope includes Worten, FNAC, Darty, OnBuy, Cdiscount and selected Mirakl-powered operators, with different capabilities per platform.
Does Autopricy use generative AI to choose prices?
Core repricing decisions use explicit rules and boundaries, not a generative model choosing prices autonomously.
What happens when marketplace data is missing?
The workflow should skip or expose an exception rather than invent a competitor price or mark an unverified action successful.
Can I begin with only a few products?
Yes. A limited scope is the preferred way to validate identity, rules, submission and confirmation before scaling.
Test the workflow on a real store
Start with one supported store, a controlled product scope, explicit boundaries and visible platform results.
yuanyongvia@gmail.com