A Xero sync that quietly stopped: refresh tokens, quiet spells and parallel refreshes

Token lifetimes in plain terms

Xero access tokens last 30 minutes. A refresh token lets the integration obtain a new access token without the user, but Xero says an unused refresh token expires after 60 days, after which the user has to authorise the app again. Every successful refresh returns a new refresh token that must be stored in place of the old one. Xero's token page describes a refresh token as valid for up to 60 days, and we found no Xero page that gives an expiry date for an individual token; that is our reading of the documentation, not a statement by Xero. An integration that wants to warn people therefore has to record its own timestamps.

How a sync stops without any error on the report

A sync that runs only quarterly can cross the 60-day limit between runs. One that runs often can still lose its connection if the new refresh token is not saved: for example the process crashes between receiving it and storing it, or two workers refresh at the same moment and one stores the older token. Xero lets the previous refresh token be retried for 30 minutes if a response was not received, which helps with a crash but not with a long outage. A demo organisation that Xero resets after 28 days also stops being a valid connection, which matters if a test setup is mistaken for a live one.

• Check when the last refresh succeeded and when the last sync run completed.
• Look for a pattern of the first failure after a quiet period.
• Check whether two processes share one connection.

What the owner can see and who must act

Xero says that after a refresh token expires the user must authorise the app again, which means a person doing it in their own browser, because it grants access under that person's identity. It is not something a developer can do for them, and not something we do. What others can do is make the lapse visible early: store the last successful refresh time and the computed latest expiry, show them beside the last run result, and warn the connection owner well before the date. Make the refresh single-threaded so two workers cannot overwrite each other's token.

• Agree who owns the connection and how they are told.
• Keep credentials out of tickets, logs and chat; share only dates and run identifiers.

Separate connection causes from code causes

A lapsed connection looks like a code bug and a code bug can look like a lapsed connection. The organisation endpoint can tell you whether you are talking to the demo company and whether lock dates are set, which are two other reasons runs may behave oddly. Establish which family the failure belongs to before changing code; a fix to rate pacing will not help an expired connection.

What fits, what does not, and how it is accepted

This is the kind of failure the standing service "Keep a finance sync healthy: failed runs, lapsing connections and duplicates reviewed" watches for, at £345 a month. The price is untested and confirmed after your enquiry; billing is monthly under written terms. Where your sync records the time of its last successful connection refresh, it counts from that time against the documented 60-day limit for an unused refresh token and warns you when a lapse is near, as an estimate; where it does not, it uses the last successful run and says so. It says exactly what the connection owner must do, never holds your credentials and never renews a connection itself.

It does not rebuild your sync or guarantee a response time. Each month you receive the runs seen, problems found and how each ended, which you can compare with your own run history. This guide is written from vendor documentation read on 11 October 2026 and nothing was run against a live organisation. Send invented examples and counts first, never credentials, bank details, invoices or customer records; real records are handled only after written agreement through a secure handoff.