Can you integrate a system that has no API?

Yes, through four routes

An API is the shortest route, not the only one. Older ERP packages, accounting software on a local server and supplier portals often have no REST API. They nearly always have another way out. In order of preference:

The order follows from two things: how fresh the data is, and how much can break without anyone noticing. A SOAP service returns a fault when something goes wrong. A file that does not arrive returns nothing. A portal that moves a button returns nothing either, and the script reads an empty page.

An integration often uses two routes side by side. Stock comes as a nightly file and orders go back through the import folder. Or the ERP is read through a database view and written through its import function.

SOAP and the database: the routes that behave like an API

SOAP web services

SOAP wraps every request in an XML envelope with a Header for authentication and a Body for the request; an error comes back as a Fault. The functions on offer are described in a WSDL file. For an integration it is an API with more text per message. The work is in the session, which often expires after some minutes and has to be renewed, and in the data types: an amount as 12.50, a date without a time zone, an empty field that comes back as a missing element or as empty text. A stock request to a generic SOAP service looks like this:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
    <SessionId>4f1c9a52</SessionId>
  </soap:Header>
  <soap:Body>
    <GetStock>
      <ItemCode>HX-4410</ItemCode>
      <Warehouse>RENO</Warehouse>
    </GetStock>
  </soap:Body>
</soap:Envelope>

QuickBooks Desktop is the common US case. Intuit's QuickBooks Web Connector is a Windows application installed on the same machine as QuickBooks, or on the same network. The integration's web service implements the methods defined in the Web Connector WSDL, and the two exchange qbXML. The Web Connector starts every exchange, on a schedule or by hand, so no firewall port is opened at the client. Two consequences follow:

• The data is as old as the schedule. The auto-run interval is set in minutes. With an interval of 15 minutes, an order placed in the store waits up to 15 minutes before QuickBooks sees it.
• The machine has to be on. The Web Connector runs on the computer that holds QuickBooks. When that computer is off, nothing is exchanged, and orders wait in the integration's queue until it is back.

A read-only view on the database

A package that runs on its own server keeps everything in a database. The administrator can create a view with exactly the columns the integration needs, and an account that may read only that view. For stock that is, for example, 4 columns: item number, warehouse, on hand and committed.

Three rules keep this route safe:

• Read only. Writing into tables bypasses the package's checks. An order inserted straight into the order table gets no number from the number sequence, no tax calculation and no committed stock.
• A view, not tables. An update of the package can change tables and columns. The administrator adjusts the view; the integration keeps reading the same 4 columns.
• Read from a replica when load matters. A query over 15,000 items every 15 minutes is a full table 96 times a day. On a read-only replica the people working in the ERP do not notice it.

Writing on this route goes through the package's own import, usually a file in an import folder. That brings in route 3.

Exchanging files without surprises

The most used route without an API is the scheduled export: the package writes a CSV or XML file to an SFTP server at fixed times, and the integration picks it up. SFTP runs over SSH, on port 22 by default, with a key instead of a password. Unlike an API, nothing answers back. Four things go wrong when there is no rule for them.

The third case in numbers. The ERP starts a file of 15,000 lines at 2:00:00 am and takes 40 seconds: 375 lines a second. An integration that looks at 2:00:20 finds 20 × 375 = 7,500 lines. No error is raised, because half a CSV file is still a valid CSV file.

The other 7,500 items are missing. If the rule for this source is that a missing item goes to 0, half the catalog shows sold out at 2:01. So the integration has two checks. It reads only files that no longer end in .tmp. And it compares the line count with the previous run: on a drop of more than, say, 10%, here from 15,000 to under 13,500, the file is not processed and an alert goes out.

/export/stock_20261002_0200.csv        15,000 lines   processed, moved to /archive
/export/stock_20261003_0200.csv.tmp     7,500 lines   being written, skip

The fourth case goes unnoticed longest. An export that stops after Friday's 2:00 am file is found without a check when a customer orders something on Monday that sold out on Saturday: 72 hours on old stock. The check is simple. The file is due at 2:30 am; if it is not there at 3:00 am, an alert goes out. What else goes wrong inside supplier files, from delimiters to encodings, is in supplier CSV and Excel files.

Writing through files works the other way round: the integration puts an order file in the import folder and the package reads it in. There is no receipt. So the integration checks in the next export whether the order with the store order number is in it, and reports an order still missing after 2 runs.

Portals without an export

Some suppliers offer only a dealer portal: a website with a login where stock is looked up per item. No export, no API. This is route 4, judged per portal. Three questions decide whether it works:

• What does the agreement with the supplier say? The script uses your account. The supplier should know it happens.
• How does the portal sign in? A user name and password can be automated. A code by text message on every sign-in cannot, without the supplier's help.
• How many pages are there? The script behaves like a visitor and waits between pages.

The sum for the third question: 1,200 items with a page each and 3 seconds between pages is 3,600 seconds, 60 minutes a run. That fits once a night, not every 15 minutes. A list page with 50 items per page is 24 pages and 72 seconds.

A script breaks when the portal changes. A column that moves puts a lead time in the stock field unless it is checked. The integration checks per run that the page has the expected layout and that the number of items found matches the previous run, and writes nothing on a mismatch. The store keeps the last good figure and an alert goes out. Many suppliers that will not set up SFTP will email a file every morning; an attachment in a fixed mailbox is route 3 with the same four checks. Supplier sources are covered on supplier feeds.

Sometimes asking is the shortest route

A concrete request to the software vendor or the distributor often gets further than a technical detour. "Do you have an API?" gets a no. This request can get a yes from whoever runs the package:

Can you put a CSV file in an SFTP folder every night at 2:00 am with:
item number, UPC, available quantity, expected ship date
File name with the date, comma as delimiter, UTF-8.

That is 4 fields, 1 time and 3 rules for the format. In a package with an export module it is a setting.

Two things to check before concluding there is no API. In several packages the API is a separate module or part of a higher license tier, so it is switched off rather than absent. And an API that exists can lack the field you need, such as a quantity break price or an expected date. Then that one field comes through an export and the rest through the API.

Checking which data a connection can actually access

The name of a package says little about whether it can be integrated. What decides it is whether there is a fixed, repeatable way to get data out and put data in. There are four routes, in order of preference:

Having an API is not the same as having the fields you need. QuickBooks Online is an example: its Item record has one QtyOnHand and no location field, so stock per warehouse is not in the API at all. It has to come from the system that counts per location. Files have their own failure points: a reused filename, a file read while it is still being written, an export that silently stops. The routes are covered in integrating a system without an API, the formats and transports in supported sources, and supplier files in supplier feeds.

What this means for your integration

For a system without an API we build the integration on the way out that the system does have, with the checks that belong to that route: unique file names, an archive, an alert on a missing or shrunken file, and a queue so an order does not disappear silently. Then we host and run it. In the dashboard you see per run which file was processed and how many lines it held.

When the source changes, a new column in the export or a portal with a new layout, we adjust the integration. The flows we build are on integrations. Tell us which system it is, and you hear which route it can take.