If you cannot explain what a sync did, you cannot trust it.
Start here:
What a sync log should capture (minimum viable)
For each sync run:
- direction: inbound/outbound/bidirectional
- entity type: contacts, invoices, payments, etc.
- status: started/processing/completed/failed/partial
- timestamps: started_at, completed_at, duration
- counts: processed/created/updated/skipped/failed
- error summary + sampled details (not a 10MB blob)
This is what makes support and operations measurable.
Partial success should be explicit
In real systems:
- some records will succeed
- some will fail due to validation or mismatches
If the system hides partial success, teams either:
- rerun blindly, or
- stop trusting the integration
Explicit partial status makes it possible to fix only what failed.
How sync logs connect to incident response
When an incident happens (token expiry, upstream outage):
- logs show impact
- you can prove what did and did not sync
- you can prioritize recovery tasks
What to do next
- Operate Xero connectivity with status + logs: Xero integration (Dubai)
- For broader integration infrastructure: ERP webhooks (Dubai)
- For controlled developer access: API key management (Dubai)