Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

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.

Describe my issue Send a message

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.

Carry on with the right page

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

outil
api
sens
frequence (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

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.

Related pages