How to Integrate Software That Has No API: Options and Risks

You can still integrate software that has no API. The usual routes, from most to least reliable, are: a direct database connection, scheduled file exports and imports, reading the emails or reports the system already sends, and automating its screens the way a person would. The right choice depends on how fresh the data needs to be, whether it flows one way or both ways, and how much maintenance you are willing to take on when the old system changes.

Most businesses meet this problem with a system they cannot easily replace, such as an ageing accounts package or a supplier portal. The rest of this guide explains how to integrate software that has no API without creating a fragile mess that only one person understands.

First, check that the software really has no API

"No API" often turns out to mean "no API on our plan" or "no API anyone has mentioned". Before designing a workaround, ask the vendor directly. These questions usually settle it:

• Is there an API on a higher subscription tier, or through a partner or developer programme?
• Does the newer or cloud-hosted version have one, even if the version you run does not?
• Can the system send webhooks (automatic notifications when something changes)?
• Is there a supported way to read the underlying database, such as an ODBC connection or a reporting user?
• Are there scheduled exports, an SFTP drop folder, or an import format the system accepts?
• What does the licence agreement say about automated access?

Get the answers in writing. A supported route, even an awkward one, is cheaper to run than an unofficial one any update can break.

What are the options when there is no API?

Direct database access

If the software runs on your own server or a private cloud machine, its data almost certainly lives in a standard database. Reading from it is often the fastest and most dependable integration available. Writing to it is a different matter: the application may expect several tables to change together, or run checks in its own code that a direct write skips. As a rule, read from the database freely, but put data in through the application's own import or interface unless the vendor confirms direct writes are safe.

Scheduled file exports and imports

Many older systems can export reports on a schedule and import files in a fixed format. A small job can pick up the export, transform it, and drop it where the other system expects it. This is unglamorous but robust, provided you handle the edge cases: files that arrive half-written, duplicate rows, changed column orders and the day the export silently stops.

Reading emails and reports

If a system emails order confirmations, invoices or alerts, those messages are a data feed. A parser can read each one and pass the details on. This works well for one-way flows, such as pushing new orders into a delivery tool, and is easy to monitor because every message leaves a trail.

Integration platforms

Tools such as Zapier, Make and Power Automate can move data between common applications without code. Even when the old system has no connector, these platforms can pull data into a spreadsheet automatically or push it on to other systems using file, email or folder triggers. They suit simple flows but struggle as logic and volumes grow.

Screen automation (RPA)

Robotic process automation means a software robot logs in and works through the interface as a member of staff would: opening screens, copying fields, pressing buttons. Browser-based systems can be driven the same way. It is sometimes the only option, but it is the most fragile. A moved button, a new pop-up or a slow page can stop it. Newer AI-driven tools cope better with small layout changes, but they do not remove the need for monitoring. If you are considering this route, our AI agents and automation work covers when it is worth it and when it is not.

A custom API layer

Where several tools need the same data, it is usually better to build one small service that talks to the old system, by database, files or automation, and offers everything else a clean, documented API. Your website, CRM and reporting tools then connect to that, not to the legacy system. When the old system changes, you fix one place. There is now a whole category of vendors selling API layers for software that lacks them, which shows how common the problem is; for a single business, a bespoke layer shaped around your own processes is often simpler.

How do you choose the right approach?

Work through these questions in order:

1. How fresh does the data need to be? If overnight is fine, scheduled files are hard to beat. If staff need it within seconds, look at database reads or a custom layer.
2. Which direction does it flow? One-way reads are far easier and safer than two-way sync. Two-way sync needs rules for conflicts, such as which system wins if a record is edited in both.
3. How much data, how often? Screen automation that handles twenty records a day may be fine; at two thousand it becomes slow and fragile.
4. How often does the old system change? A package that has not been updated in years is a stable target. A cloud tool that changes its interface every month is not.
5. What happens if it fails for a day? If a missed sync means unpaid invoices or unshipped orders, invest in monitoring and choose the sturdiest method you can.
6. How long will you keep the old system? If it is being replaced within a year, a cheap, temporary bridge is reasonable. If it is staying for five years, build properly.

What can go wrong, and how do you reduce the risk?

Integrations without an API rarely fail loudly. They fail quietly, and someone notices weeks later that figures do not match. Plan for that from the start.

• Silent failures. Every job should log what it did and alert someone when it fails or processes nothing. A daily reconciliation, comparing counts or totals in both systems, catches problems that alerts miss.
• Vendor updates. Ask the vendor to tell you about upgrades, test integrations before upgrading, and keep the old version available to roll back to.
• Licence terms. Some agreements restrict automated access or database connections. Check yours before building, and keep a record of any permission you get.
• Security. Bots and scripts need credentials. Give them their own accounts with the minimum access required, store passwords in a proper secrets vault rather than in scripts, and remove access when the integration is retired. Our cybersecurity and backups team can review this.
• Personal data. If customer or staff data passes through the integration, the data protection rules in your country apply to it just as they do to the original system. Rules differ between the UK, Saudi Arabia and Pakistan, so confirm your obligations before personal data starts moving.
• Key-person risk. Workarounds built by one person over a weekend tend to be undocumented. Write down what runs, where, when and how to restart it.

Someone has to own the integration after launch. Whether that is an internal person or a managed maintenance arrangement, decide before go-live, not after the first failure.

When should you replace the system instead?

Integration is usually cheaper than replacement, but not always. Consider replacing the system, or rebuilding the part of it you rely on, when:

• you are maintaining several fragile workarounds just to keep data moving;
• staff still re-key the same data into two places despite the integrations;
• the vendor no longer issues updates or security fixes;
• the system blocks something the business now needs, such as customer self-service or mobile access.

A sensible middle path is often to wrap the old system in a custom API layer now, then move functions off it one at a time. Everything already connected to the layer keeps working while the system behind it changes.

Frequently asked questions

If you have a system that will not talk to the rest of your business, we can look at how it is used, check what the vendor really supports, and recommend the simplest integration that will hold up. Our software and custom development team builds internal tools and integrations shaped around how your business already works.