Integrations and automation
Connecting a system without an API: five routes, best to worst
Part of the guide: System Integration for Business: What to Do When It Breaks
Connecting a system without an API is usually a question somebody asks the fourth time they retype the same data from one window into another. Below are five routes, ranked best to worst, each with an honest note on when it is acceptable and when it becomes technical debt. Start elsewhere, though: check whether the interface really is missing. Sometimes it exists, only in a higher plan or as a paid extra.
What an API is, and why “there is no API” is often untrue
An API is a set of commands documented by the vendor that lets one program read and write data in another without a person clicking through a window. You will meet a few varieties: REST (the most common today, data usually carried as JSON), SOAP (an older XML-based standard, still present in accounting systems) and GraphQL (which lets you ask for exactly the fields you need). Access is protected by an API key, a token, or the OAuth 2.0 standard — a mechanism in which the system grants an application limited permissions without handing over your password.
Data then travels in one of two ways: by webhook, a notification the system sends the moment something happens, or by polling, checking every few minutes whether anything changed. The separate piece on system integration in a company unpacks that difference. Some older accounting and warehouse systems on the Polish market — the ones a company operating in Poland is likely to already run — have no public, supported interface at all. That is a real situation, not an excuse from a build partner. The range of interfaces also differs between versions of the same product, which applies to Comarch ERP Optima and Comarch ERP XL, enova365, Symfonia, Subiekt GT and Subiekt nexo, Streamsoft Prestiż, Microsoft Dynamics 365 Business Central and SAP.
Questions to ask the vendor before you conclude there is no API
Ask the vendor in writing before you decide the interface does not exist — silence on the product page is not evidence. An API is sometimes available only in a higher plan, as a separate paid module, in a newer release, or exclusively to implementation partners. Email has a second benefit: the answer stays in writing, so you can show it to your build partner instead of relaying a phone call.
"Does [system name], in the version we use, expose a supported API for reading and writing contact records, products, stock levels and orders? If so, please send a link to the documentation, tell us which plan or module it sits in and whether it carries an extra charge, the authentication method (API key, token, OAuth 2.0), request limits, access to a test environment, and how changes are announced and older versions maintained. If not, please confirm whether you permit scheduled file exports to an SFTP server and reading data directly from the database, and whether such use is covered by support."
Three parts of the answer decide the cost for years: whether interface changes are announced in advance, how long older versions stay supported, and whether a test environment exists where an update can be checked before it reaches you. The question of how to connect a system without an API only makes sense once you have a written answer that the interface genuinely is not there.
Route one: the vendor’s official, supported API
An official API is the only route somebody outside your company is obliged to maintain, which is why every project starts by checking whether it is available. The vendor documents the interface, announces changes, and answers when something stops behaving as documented. What stays on your side is your own client: error handling, retries and logs.
It turns into technical debt only if you build the connection with no logs and no dead letter queue — the place failed messages land. Then the first interface version change ends in guesswork. Ask separately about request limits: on a first import of tens of thousands of records they can decide the shape of the whole solution.
Route two: files exchanged over SFTP on a schedule
File exchange is the oldest route that still makes sense: one system drops a data file at an agreed hour and the other collects and imports it. SFTP is an encrypted way of sending files to somebody else’s server and fetching them back; inside the file you will usually find CSV, XML or JSON. This can be a permanent answer rather than a stopgap, on one condition: the process can run in batches, meaning nobody is waiting for the result on screen.
To survive for years it needs three things: a written format agreement (column list, character encoding, separator, date and amount format), a folder for rejected records with the reason, and an alert when the file does not appear at the agreed hour. At a vendor update it usually breaks quietly — a column is added or the encoding changes, and the import loads rubbish without reporting an error. Failure here looks like silence, so watch for missing files as carefully as for errors.
Route three: going straight into the system database
Database integration means reaching for data while bypassing the program itself, straight into the store where it keeps its tables. It works, and it is sometimes the only option, but it is technical debt with a deferred payment date: the vendor never promised the table structure would stay put, so it gets broken at later updates. Writing to the database is far riskier than reading, because it skips the rules the program applies itself: document numbering, recalculations and change history entries.
The acceptable variant is narrow — reading for a report, ideally from a database copy, after written confirmation that the vendor does not object. Only your company maintains it, because that use is usually outside support. The failure can be the most expensive of all five routes: data drifts apart quietly and surfaces at stocktake or month-end close. Before you decide, check the system licence and what personal data will end up in the copy. This is general information, not legal advice.
Route four: manual CSV import and export
Moving files by hand is not an integration, it is a procedure carried out by a person, and it should be planned as one. CSV is a plain text file holding a table, with fields separated by a comma or a semicolon. The route is defensible with one direction of flow, a small volume, one responsible person and a written procedure — as a bridge for a few weeks, not a few years.
It becomes debt on the day the export has to happen daily. Failure comes with no error message here: somebody falls ill, goes on holiday, or imports the same file twice and duplicates appear. With stock levels this route is especially treacherous, because the data ages within hours, which the piece on inventory synchronisation between a shop and an ERP sets out. If you go with CSV, set the switch-off date before you start the procedure.
Route five: reading from the screen — scraping, and why almost never
Scraping is a program that logs into the panel like a person and reads data off the screen, because no door for programs was ever opened. It is in play in one narrow case: a one-off export of your own data before a migration, read-only, on an agreed date and after written confirmation that the vendor does not forbid it. As a permanent connection carrying a process your sales depend on, it is the worst available choice.
There are three reasons and none is a technical detail. First, it breaks with any change to the look of the panel, and the vendor has no obligation to announce one. Second, it requires storing a real user’s login credentials, so the system history attributes every operation to that person, and two-factor authentication usually blocks the automation outright. Third, some systems explicitly forbid automated access in their terms — check that before anybody writes code.
Connecting a system without an API: the five routes side by side
The choice comes down to three questions: who is obliged to maintain the connection, what happens to it at the vendor’s next update, and how you will know it stopped working. The table below answers them for each of the five routes.
| Route | When it is acceptable | What breaks at an update | Who maintains it | What failure looks like |
|---|---|---|---|---|
| Supported API | Always, where it is available | The interface version, but with notice | The vendor on its side, you on yours | A readable error and a message in the queue |
| Files over SFTP | Batch processes, nobody waiting for the result | Column layout, encoding, date format | Both sides, per the format agreement | Silence: the file never arrived or imported wrongly |
| Database | Reading for a report, with vendor consent | Table structure, without notice | Your company alone | Quiet data drift, visible weeks later |
| Manual CSV | A bridge for a few weeks, one direction | Nothing technically, everything organisationally | One named person in the company | A missed export, or duplicates after a double import |
| Reading from the screen | A one-off migration of your own data | Any change to the look of the panel | Your company alone | Incomplete data pulled with no error reported |
Whichever route you pick, ask for the same minimum set: logs with the message content, an alert on silence, a dead letter queue, a retry procedure and one owner inside the company — the list common to every system integration project. Whether you build the flow in a ready-made tool or in your own code is a separate decision, sorted out by the comparison of Make, n8n and a custom integration. Cost follows the same logic as mobile app development cost: you pay for edge cases and agreements, not for the number of fields being copied. If you do not know which route to take, describe both systems to us — the conversation should start with what data has to move and how often, not with the name of a tool.
Checklist
Send the vendor a written question about the API and ask for a link to the documentation and the plan the interface is included in.
Check your contract and the system terms for whether you are allowed to read the database directly and to log into the panel automatically.
Decide whether the process can run overnight in batches or whether somebody is waiting for the result on screen — that settles half the choice.
Name one person on your side who owns the connection and has a contact at the vendor of each system.
Order an alert on silence: a notification when the file does not arrive at the agreed hour, or when no event comes through for a few hours.
Put in the contract with your build partner what happens after a vendor update and who pays to repair the connection.
Set the date on which the temporary solution is switched off, and put it in the calendar before you turn it on.
Frequently asked questions
- How do I connect my shop to a warehouse system that has no API?
- First get written confirmation from the vendor that the interface really is absent from your version and plan. If it is, the safest route is a scheduled file exchange: the warehouse system exports stock levels and product records to an SFTP server at a fixed hour, and the shop downloads and imports them. That needs a written file format agreement, a folder for rejected records and an alert when the file does not arrive on time. It only works for batch processes — if the customer has to see current stock in real time, the conversation goes back to an interface on the warehouse system side.
- Is integrating through a system database safe?
- Reading from the database for reporting, ideally from a copy, is often acceptable. Writing straight into it is risky, because it bypasses the rules the program applies on save: document numbering, recalculations and change history entries. That kind of integration is usually outside vendor support, and the table structure can change with any update. Check what the system licence says before you decide. This is general information, not legal advice.
- What happens to the integration when the vendor updates the system?
- It depends what you connected through. A supported API has versions and announced changes, so you have time to react. File exchange breaks when the column layout, the character encoding or the date format changes — usually quietly, with no error message. Database integrations and screen reading can stop working overnight, because the vendor never committed to keeping either the table structure or the screen layout stable. Put in your contract who responds to that kind of failure and at whose cost.
- Is scraping the admin panel a good solution?
- Almost never. Scraping, meaning automated reading of data off the panel screen, breaks with every interface change, requires storing a real user login, and makes the system history attribute every operation to that person. Two-factor authentication usually blocks it, and some systems explicitly forbid automated access in their terms. It can only be defended as a one-off export of your own data before a migration, on an agreed date and after written confirmation that the vendor does not prohibit it.
- How do I check whether my system really has no API?
- Email the vendor and ask for the answer in writing — the absence of a mention on the product page is not proof. State the system version and the plan you use, and list the data you want to read and write: contacts, products, stock levels, orders. Ask for a link to the documentation, the authentication method, request limits and access to a test environment. The interface is sometimes available only in a higher plan, as a paid module, or in a newer version of the system.
- How long does it take to integrate two systems without an API?
- There is no single number, because the timeline is set by the other side's answers rather than by the code. The biggest factors are how long the vendor takes to state its position, access to a test environment, the number of fields to agree between systems, and whether records on both sides can be matched unambiguously. An honest build partner gives you a range only after reviewing sample data and documentation, not from a description of the problem alone.
Sources and methodology
These links lead to primary sources and the rules we use to prepare and update our material.