Integrations break. Plan for that instead of pretending otherwise

A permanent condition, not a defect

Every integration depends on a system somebody else controls, and that somebody will change it. APIs are versioned and deprecated, authentication requirements tighten, fields get renamed, rate limits change.

None of that is a failure of the original build. It is the ordinary weather of connecting systems, and treating each occurrence as a surprise is what makes integrations feel fragile.

The projects that go badly are the ones where nobody planned for maintenance because nobody said out loud that maintenance would be needed.

Detection is the whole strategy

You cannot prevent a vendor from changing an endpoint. You can find out within an hour instead of within a quarter.

That means health checks that verify the connection still works, alerts when volumes fall outside expected bounds, and a heartbeat that notices when something stops running entirely.

Fast detection turns a potential data quality disaster into a Tuesday afternoon fix.

Decide who owns each field

Most sync problems are not technical, they are governance. Two systems both believing they own the customer record will fight forever, and no amount of clever conflict resolution fixes an unmade decision.

Assign one owner per field. This system is authoritative for contact details, that one for billing, and the flow goes one way. Once that is settled the technical work becomes straightforward.

That conversation is often the most valuable part of an integration project, and it has nothing to do with code.

Platform or custom

Integration platforms are good value for standard connections between popular tools, with maintenance handled for you. That is a real benefit and worth paying for when it fits.

They become awkward when the mapping is unusual, the volume is high, or the error handling needs to be specific. At that point the platform is the constraint and the cost curve turns against you.

Either choice is defensible. Choosing on requirements rather than preference is the part that matters.