Integration
Before connecting two systems, confirm four things: which one owns the record, what each exposes, how failures will surface, and who holds the credentials.
In order
For every record that will move (customer, order, invoice) decide which system is authoritative. Most integration disputes are this question left unanswered, and no amount of engineering resolves it afterwards.
Does each system offer a documented API, are there webhooks for the events you care about, what are the rate limits, and how does authentication work. A system without these can still be integrated, but through fragile routes that need a named owner and a maintenance budget.
What happens when the receiving system is briefly unavailable, when a message arrives twice, or when a record is rejected. Deciding this during design costs an hour; discovering it in production costs a reconciliation exercise.
Who holds the keys, how they rotate, and who is notified when a vendor announces a breaking change. Integrations rarely break spontaneously: they break when something on either side changes and nobody was watching.
Resolve it before building. An integration that syncs both directions without an authoritative source produces conflicts that are expensive to unpick and impossible to audit.
Only if it tells you. Alerting on failures and a periodic reconciliation between the two systems are what turn a silent failure into a notification.
Before connecting two systems, confirm four things: which one owns the record, what each exposes, how failures will surface, and who holds the credentials.
You have read what we think. If you want to know what it means for your case specifically, describe it and we will tell you which parts of integration readiness checklist actually apply — and which do not.
