# My synchronisation with an external tool has stopped

> A link between two systems almost never goes down for no reason, and almost never on both sides at once. It goes down because an authorisation expired, because a format changed, or because a call limit was reached. In all three cases the refusal is explicit somewhere — you just need to know where to look.

- Source canonique : [https://allaux.fr/en/problemes/synchronisation-avec-un-outil-externe-interrompue](https://allaux.fr/en/problemes/synchronisation-avec-un-outil-externe-interrompue)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Look for the rejection code returned by the other system: 401 for an expired key, 403 for a revoked permission, 429 for a rate limit reached. The exchanges are logged in WooCommerce > Status > Logs on WordPress and in var/logs/ on PrestaShop. Then confirm the key is still active: Advanced Parameters > Webservice, or WooCommerce > Settings > Advanced > REST API.

## Which direction is broken

- The site sends nothing any more: the problem is in the triggering, on the shop side.
- The site sends but the other system refuses: the response holds a code and a message naming the cause.
- The other system sends but the site processes nothing: the receiving address changed, or a rule is blocking the call.
- Data flows but is wrong: that is not a link failure, it is a field mapping that has become inaccurate.

## The four causes I meet most

The authorisation expired. Many services issue access tokens valid for a limited time, or revoke a key when a password changes. The link works for months, then stops one morning with nothing changed on your side.

The other service changed version. A renamed field, a changed date format, a field that became mandatory: the call is refused although the code has not moved. Those changes are announced by email in advance, to an address nobody reads any more.

The call limit is reached. Services impose a maximum number of calls per minute or per day. A synchronisation processing product by product hits that limit as soon as the catalogue grows, and subsequent calls are rejected.

The certificate or address changed. A site moved to HTTPS, a changed domain, an expired certificate: the other system can no longer reach the address it has on file.

## Finding the refusal message

1. **Look for the log on the site side** — A properly written integration records every call and every response. If no such log exists, that is the first thing to add, before even hunting the cause.
2. **Look for the log on the service side** — Most platforms expose a history of received calls with response codes. If your calls are not there, they are not leaving.
3. **Replay a single call** — One product, one order. The response is far more readable than a bulk run failing on an unknown row.
4. **Check the expiry of access credentials** — Token, key, application password, client certificate: each has a deadline, and none is automatically reminded.
5. **Check what changed on the other side** — Release notes, plan change, announced migration. A link that fails with no cause on the shop side almost always has a cause on the partner side.

## A synchronisation resuming after an outage can overwrite everything

> If both systems were modified during the interruption, resuming must decide which version wins. Without that rule, synchronisation overwrites the most recent changes with stale data. That is the real difficulty of restarting, far more than restoring the link itself.

## Carry on with the right page

- **Integrations and APIs** — How I build a link that reports its failures instead of hiding them. ([/services/integrations-api](/services/integrations-api))
- **Connecting an ERP or a supplier** — The PrestaShop case, with the web service and its limits. ([/prestashop/problemes/connecter-erp-fournisseur-api](/prestashop/problemes/connecter-erp-fournisseur-api))
- **REST APIs explained** — How two systems talk, and what each response code means. ([/glossaire/api-rest](/glossaire/api-rest))
- **Webhooks explained** — When the other service calls your site, and why the call can fail. ([/glossaire/webhook](/glossaire/webhook))

## FAQ

### The provider says the problem is my site. How do I check?

By asking to see their log of received calls. If your calls are there with a refusal code, the cause is named in black and white. If they are not, the case is proven the other way.

### Should everything be resynchronised after an outage?

Rarely in full. Replaying only the missing period is faster and far less risky, provided records carry a usable modification date.

### Is real-time synchronisation better than scheduled?

Not always. Real time exposes you to every outage of the other system; a scheduled run with retry on failure is often more robust for a stock or price feed.

### Why does the link work for some products and not others?

Because those products hold a value the other system refuses: an empty field that became mandatory, an unaccepted character, a category unknown on their side. What the failing products have in common is the lead.

### Can I monitor the link without a paid tool?

Yes: a count of items synchronised per day, compared with the previous day, is enough to detect a stop. Simple to set up, and it saves discovering the failure a week too late.