Integration without an API: connecting software that has no programming interface

Programs without an API can be connected too. We use whatever the system offers: a file export, an exchange folder, SFTP or read access to the database. The integration picks up the data automatically, validates it, converts it and transfers it to the target system via API.

The problem: the legacy system can only export

Many businesses work with software that has run reliably for years but has no modern interface. It may be a local ERP, an industry solution or an Excel list that has become the central tool. The data only comes out through an export.

So someone exports a CSV file every morning, opens it, corrects columns and imports it into the next program. Or the data is simply retyped. Errors happen: wrong delimiters, shifted columns, umlauts that break during import, duplicate records because the export was read in twice. And when the responsible person is on vacation, the export sits there.

How we connect systems without an API

We look at which outputs the system has and choose the most stable one.

• File export

  Many programs can write CSV, XML or Excel to a folder automatically. The integration picks up the file there once it is complete.

• SFTP

  If the system is hosted by a service provider, we exchange files via a secured SFTP access, in both directions.

• Database

  If the program has its own database, we read directly from it in agreement with you and the vendor. We write to it only if that is expressly permitted.

• Import in the target system

  Some target systems accept files, for example DATEV via the DATEV format. Then we generate exactly that file.

Detecting changed records

A common problem: the export contains all records every time, and there is no modification date. The integration then stores a fingerprint of its content for each record. On the next run it compares and transfers only what is new or has changed. It detects deleted entries by their absence from the export and handles them by a fixed rule.

Validating instead of importing blindly

Before anything is transferred, the integration checks every file: Do columns and delimiters match? Are mandatory fields filled? Are amounts and dates valid? Is the character encoding right? Faulty rows are set aside with a reason, and the rest carries on. Each file is processed only once, even if it accidentally sits in the folder twice. Everything is logged, and errors trigger an alert.

1. Export file is picked up and validated on schedule
2. Changed records are detected and converted per run
3. Data is transferred via API or import file per run
4. Feedback is placed back as a file if desired

Typical data objects

When there is an easier way

Not every export needs a custom integration. If you import a file once a month and it takes a few minutes, the effort is hardly worth it. Also check whether the vendor now offers an API or an update with an interface. Some automation services can process files from cloud folders. With local databases, proprietary formats or high validation requirements, though, they reach their limits. More in the glossary under iPaaS and middleware.

A custom connection is worthwhile when the export occurs daily, errors are expensive or several systems are involved. It is also often the interim step to keep using a legacy system until a switch is due.

Examples by industry

Businesses with grown industry software are often affected, for example in skilled trades, wholesale or logistics. The basics of integrations in general are explained in the glossary under integration and data mapping.

Process

In the free check (30 minutes) we look at which exports and access the system offers. It is best to send us a sample file in advance, without real customer data. Within 3 working days you receive a fixed-price quote, and implementation usually takes 2 to 4 weeks. Details under process and pricing.

Updated: 10/21/2026