How do I connect two systems that don't integrate?

Question

VX-N · Accepted Answer

If both have an API, they can be connected — through a middleware platform for standard cases, or with custom code when the logic is specific. If one has no API, the fallbacks are scheduled file exports, email parsing, or database access, in that order of preference. Decide what the source of truth is before wiring anything. Two systems syncing both directions without a designated winner produce conflicts that are far harder to debug than the original manual step. The working discipline is a field-ownership map: for every shared field — phone, status, amount, owner — write down which system may change it and which merely displays it. One-way sync per field is boring and correct; symmetrical two-way sync is a standing invitation for the two systems to overwrite each other forever. Also decide what happens when the sync fails, because it will. APIs change, credentials expire, vendors deprecate endpoints, rate limits reject a burst of updates. Silent failure is worse than no automation, since people stop checking. The build needs three unglamorous pieces: a retry that will not create duplicates when the same event arrives twice, an error queue where failed records wait visibly for a human instead of vanishing, and an alert that fires when the connection has been quiet longer than it should be. Integrations rarely fail loudly; they fail quietly and get discovered at month end. The connection method matters less than people think, but the order of preference is real. Webhooks or event triggers beat polling when the vendor offers them — changes arrive in seconds instead of on a schedule. Middleware platforms are fast to stand up and priced per task, which is fine at modest volume and a real line item once the sync runs on every record. Custom code earns its keep when the transformation logic is specific to your business: mapping picklists that do not match, splitting one system's record into another's two, normalizing formats. When one side has no API, be honest about the fragility you are accepting. Scheduled exports are stable but stale by hours; email parsing works until the vendor redesigns the notification template; direct database access is powerful and breaks without warning on the vendor's next update, if the terms allow it at all. All three are legitimate bridges — but they are bridges, and the plan should include what triggers replacing them. Before the first record flows, clean and deduplicate what is already in both systems, or the automation will faithfully propagate the mess. And test with the weird records, not the clean ones — the contact with two emails, the deal with no owner, the name with an accent. The clean records were never the problem.