What if our systems do not integrate with automation tools?
By Aaron Melton,
Almost everything integrates. Modern platforms expose APIs, and where a native connector does not exist we build the bridge in Python or JavaScript. Older systems usually expose a database, a file export, or an email that can be worked from. Integration feasibility is one of the first things we verify in discovery, before you commit to a build.
The four ways in
Every system we have connected offered at least one of these routes.
An API. The clean path. The platform publishes a way for other software to read and write its data. Most modern business tools have one, and automation platforms such as n8n have ready connectors for the common ones.
A database. Many older or self-hosted systems sit on a SQL database. With read access, we can pull from it directly; with care, we can write to it. We have synced SQL databases into NocoDB to give staff a usable interface over data that used to need a database administrator.
A file export. If a system can produce a spreadsheet or a report on a schedule, that file is an integration point. It is not elegant, but it is reliable, and it is often the fastest route to a working first version.
Email or a web interface. As a last resort, a system that sends notification emails or has a web form can be driven from those. It is the most fragile option, and we say so, but it can bridge a gap while a better route is arranged.
What "no native connector" actually means
When a platform is not on an automation tool's connector list, it means nobody has packaged the integration, not that it cannot be done. If the platform has an API, writing the missing connector is routine work. We have connected CRMs, e-signature tools, OneDrive and SharePoint file flows, and Airtable lead pipelines, and several of those needed a small custom piece in the middle.
How we check feasibility before you commit
In discovery we ask which systems hold the data, who administers them, and what access already exists. Then we confirm the route in: an API key, a database login, a scheduled export. If a clean route exists, we say so. If only a fragile route exists, we tell you what it will cost to maintain and whether a better option is worth pursuing. You get that answer before any build is scoped, so you are never paying to discover that an integration is harder than expected.
Designing the integration properly
Connecting two systems is the easy part. The work is in the decisions around it: which system owns each piece of data, which direction each sync runs, what happens with duplicates and deletions, and how partial failures are retried. We settle those in design, build on infrastructure you control, log every run, and document the whole thing so the next person can maintain it.
What this looked like for one client
For a county government we connected a SQL database to NocoDB so staff could work with internal data through a friendly interface, and later upgraded their self-hosted n8n platform across a major version with every workflow tested before and after. Neither system had a packaged connector for the other. Both integrated.