# Multi-Store Synchronization — Installation and Configuration Guide
> This guide covers installing the Multi-Store Synchronization module, connecting two PrestaShop installations and fully configuring catalog synchronization. Requirements Two PrestaShop 8.0 to 9.x installations (databases and hosting may be separate).…
- Page:
- Language: en
- Last updated: 2026-07-15
- Other languages: [fr](https://www.datafirefly.com/documentation/synchronisation-multi-boutiques/index.md), [es](https://www.datafirefly.com/es/documentation/sincronizacion-multi-tienda/index.md), [de](https://www.datafirefly.com/de/documentation/multi-shop-synchronisation/index.md), [it](https://www.datafirefly.com/it/documentation/sincronizzazione-multi-negozio/index.md), [pl](https://www.datafirefly.com/pl/documentation/synchronisation-multi-boutiques/index.md), [pt](https://www.datafirefly.com/pt/documentation/synchronisation-multi-boutiques/index.md), [nl](https://www.datafirefly.com/nl/documentation/synchronisation-multi-boutiques/index.md)
- Index:
This guide covers installing the **Multi-Store Synchronization** module, connecting two PrestaShop installations and fully configuring catalog synchronization.
## Requirements
- Two PrestaShop 8.0 to 9.x installations (databases and hosting may be separate).
- The PHP cURL extension enabled on the store that drives the synchronization.
- The webservice enabled on the remote store, with a dedicated access key.
The module is only installed on the store that _drives_ the synchronization. The remote store simply needs its webservice enabled — no module to install there.
## Installing the module
1. In the back office of the driving store, open **Modules > Module Manager**.
2. Click **Upload a module** and send the `dfmultisync.zip` file.
3. Once installed, the module adds the **Advanced Parameters > DF Multi-Store Sync** menu.
## Enabling the webservice on the remote store
On the store to be connected:
1. Open **Advanced Parameters > Webservice**.
2. Set **Enable PrestaShop's webservice** to _Yes_ and save.
3. Click **Add new webservice key**, generate a key, then grant `GET`, `POST`, `PUT` and `DELETE` permissions on: `categories`, `products`, `images`, `combinations`, `stock_availables`, `specific_prices` and `languages`.
4. Save and copy the generated key.
Without `DELETE` permission on `specific_prices`, specific price synchronization will fail: the module mirrors the remote set through delete-and-recreate.
## Adding a remote site
1. Go to **DF Multi-Store Sync > Remote sites** then **Add remote site**.
2. Enter a name, the remote store's root URL (e.g. `https://store-b.example.com`) and the webservice key copied earlier.
3. Save, then click **Test** in the list to verify the connection.
The **Test** button actually queries the remote webservice. If it fails, check the URL (with the `https://` protocol), the key, and that the webservice is enabled on the remote side.
## Creating a sync profile
A profile describes _what_ to synchronize, _in which direction_ and _how_ to arbitrate conflicts.
### Direction: push or pull
- **Push** — the current store is the source and sends its data to the remote site.
- **Pull** — the remote site is the source; the current store receives its data.
### Entities
Select the entities to synchronize. They are always processed in this order to respect dependencies: **categories → products → stock → specific prices**.
### Options
- **Sync images** — on push, new local images are sent; on pull, images are downloaded when the product is created.
- **Sync specific prices** — available in push mode only.
- **Batch size** — number of entities processed per cycle (1 to 25). Lower it if the remote server is slow.
## Conflict strategies
A conflict occurs when both stores have edited the same record since the last sync. Four strategies are available:
- **Source wins** — the source always overwrites the target.
- **Target wins** — conflicting entities are skipped.
- **Newest wins** — modification dates are compared.
- **Manual** — conflicts are queued for arbitration.
## Running a first synchronization
1. Open the module **Dashboard**.
2. On the profile row, click **Run now**.
3. Synchronization runs in batches: the progress bar shows live counts of created, updated, skipped, conflicting and errored entities.
Synchronization works within a time budget (25 seconds by default) and automatically resumes where it stopped. On a large catalog, several cycles chain together without intervention.
## Automating with cron
1. Enable the **Cron** option on the relevant profiles.
2. Copy the cron URL shown on the dashboard (secured by a token).
3. Add it to your server's crontab, for example every fifteen minutes:
```
*/15 * * * * wget -q -O /dev/null "https://your-store.com/module/dfmultisync/cron?token=YOUR_TOKEN"
```
The cron URL token is confidential: it authorizes triggering synchronizations. Do not share it or expose it publicly.
## Resolving conflicts
With the **Manual** strategy, conflicts accumulate in the **Conflicts** tab. For each pending row:
- **Keep local** — forces the push of the local version.
- **Keep remote** — forces the pull of the remote version.
- **Ignore** — marks the conflict as handled without transferring anything.
## Logs and monitoring
The **Logs** tab keeps a history of operations (info, warning, error), filterable by level and date. Logs are purged automatically after 30 days.
## Troubleshooting
### The connection test fails
Check that the webservice is enabled on the remote side, that the key is correct and that its permission profile covers the resources listed above. Make sure the URL includes `https://`.
### Some products are skipped
The module matches products and combinations by **reference**. A product without a reference, or whose reference differs between the two stores, cannot be matched for stock. Set consistent references.
### Specific prices do not sync
Specific price synchronization is **push only** and requires the `DELETE` permission on `specific_prices` on the remote side.
### Synchronization seems slow
Lower the profile's batch size and let cron chain the cycles. The first run is always the longest; subsequent runs only transfer entities that actually changed.