No API is not no integration. It is four honest doors and one we will not open.
A system with no API can still be integrated through four doors: scheduled file drops, parsing the emails it sends, read-only access to its database, and its own export and import tools. Screen scraping and automations that log in as a person are refused. Which door is open decides the design, the cost and the risk.
What no vendor publishes — a pattern, not a product
- Documentation
- Not published — no public API documentation exists.
- Authentication
- Not published.
- Token lifetimes
- Not published.
- Rate limits
- Not published.
- When you exceed one
- Not published.
- Pagination
- Not published.
- Webhooks
- Not published.
- Event verification
- Not published — no payload signature scheme.
- Retry behaviour
- Not published — no retry policy.
- Bulk operations
- Not published — no batch endpoint or bulk limit.
- Test environment
- Not published — no sandbox terms.
- Data location
- Not published — the vendor does not say where the data is stored.
- Cost of API access
- Not published.
Every line above is the vendor’s own documentation, fetched 3 September 2026, linked so you can check it yourself. All thirteen fields are marked not published — by construction, because this is a pattern rather than a vendor. The full capability register puts this beside the other systems.
What a custom or legacy system allows, and why every cell above is empty
Not a product. The pattern for every system with no API worth the name: the Access database in the office, the ERP the vendor stopped supporting, the supplier portal that only emails PDFs. Every field below is null because there is no vendor to publish anything — the work is deciding which of four honest doors is open, and refusing the fifth.
This is the one page in the integration cluster where the published-fact strip is deliberately blank. There is no vendor. There is the Access database the previous office manager built in 2009, the manufacturing system whose supplier went out of business, the supplier portal that emails a PDF, the payroll export that only comes out as a fixed-width text file. None of them has a developer portal. All of them hold data the business runs on.
The honest position is that we cannot tell you what these systems allow until we have looked at yours. What we can do is show you the four patterns that work, the one we refuse, the published facts that shape each, and the questions to answer before anyone quotes. For the systems that do publish an API, the capability register covers them field by field; for whether a build is justified at all, start at custom versus off-the-shelf.
The four doors, in the order we try them
Cheapest and least fragile first. Most legacy jobs are solved at the first or second door, and the third and fourth exist for the cases that are not.
- KNDR·011. The system’s own export and importNearly every product can export a CSV and many can import one. Tradify, which publishes no API at all, exports jobs, invoices, quotes, bills, customers, sites, suppliers and timesheets to CSV and imports jobs from a template (Tradify help centre, fetched 3 September 2026). Dull, supported by the vendor, and the right first answer.
- KNDR·022. Scheduled file dropsA file lands in a folder at 6pm, something picks it up. This is how supplier statements, bank files and payroll have moved for thirty years. The trap is that CSV has no formal specification — RFC 4180 says so in its own text, and it is an Informational document from October 2005, not a standard (RFC 4180, fetched 3 September 2026). Every export is its own dialect and the parser has to be built for that one.
- KNDR·033. Reading the emails the system sendsIf a portal can only email you a PDF, the mailbox is the API. Microsoft Graph allows 10,000 requests per 10 minutes and four concurrent per mailbox to read it properly, with change notifications instead of polling (Microsoft Graph throttling limits, fetched 3 September 2026). Detail on the Microsoft 365 page.
- KNDR·044. Read-only database accessPowerful and easy to regret. Reading a legacy system’s tables directly works until the vendor renames a column; writing to them bypasses every rule the application enforces. We build this read-only, from a replica or a nightly copy, never against the live production database, and never as a write path.
Unsupported software is the risk, and the dates are public
Old is not the problem. Unsupported is. A twelve-year-old system that still gets security patches is a maintenance item; a three-year-old one whose vendor has gone is an exposure. The dates that decide which one you have are published by the software vendors, and three of them landed in the last twelve months.
Windows 10 Home and Pro reached end of support on 14 October 2025 (Microsoft lifecycle, fetched 3 September 2026). SQL Server 2016 — the database under a great many small-business line-of-business applications — leaves extended support in July 2026 (Microsoft lifecycle, fetched 3 September 2026). Windows Server 2012 R2 left extended support on 10 October 2023 and its paid Extended Security Updates stop on 14 October 2026 (Microsoft lifecycle, fetched 3 September 2026).
An integration inherits the exposure of everything it touches. If door four means connecting to a SQL Server 2016 instance on a 2012 R2 box, that is a security decision dressed as an integration decision, and it belongs in the quote as a line item — "replace or isolate this first" — not as a footnote. The ABS reports that 21 percent of Australian businesses experienced a cyber security incident in 2024–25 (ABS Characteristics of Australian Business, released 25 June 2026), and the OAIC received 1,205 data breach notifications in calendar 2025, the most since the scheme began and up 8 percent on 2024’s 1,112, with 716 attributed to malicious or criminal activity (OAIC, 2026).
The records outlive the system, and the law says for how long
A legacy system is usually the only place some records live, and the obligation to keep them does not end when the software does. Fair Work requires employers to keep time and wages records for seven years, legible, in English and readily accessible to a Fair Work Inspector (Fair Work Ombudsman, record-keeping, fetched 3 September 2026). If the legacy payroll module is where those sit, the migration plan needs a retention answer before it needs a cut-over date.
Privacy is the other one. Businesses with annual turnover of $3 million or less are generally outside the Privacy Act, but private health service providers are covered regardless of size, as is any business that trades in personal information (OAIC, rights and responsibilities, fetched 3 September 2026). An NDIS provider or a physio practice with a legacy client database is inside the Act, and door four on that database is a different conversation.
The practical rule: before we connect to any legacy store, we write down what it holds, how long each class of record has to be kept, and where it will live afterwards. Twenty minutes with the owner, and it prevents the most expensive kind of surprise — the one that arrives with an inspector.
Where the modern systems in our register meet the legacy pattern
Several systems we have built against have a legacy edge of their own, and knowing it saves a week. MYOB serves locally hosted AccountRight company files through the same API as cloud files, but with a username and password for that file rather than OAuth (MYOB authentication, fetched 3 September 2026) — so an office still running a file on the machine in the corner is reachable, differently. The detail is on the MYOB page.
AroFlo publishes an API but no webhooks and a daily cap of 2,000 general calls, so an AroFlo integration behaves like a legacy file drop with better plumbing: a scheduled, filtered pull rather than a live feed. Stripe offers the opposite edge — a file-based Batch Jobs API taking JSONL up to 5 GB and 2 million lines per run — which is the modern version of the file drop and the right tool for a large one-off migration (Stripe batch API, fetched 1 September 2026).
The point is that "legacy" is a spectrum, not a category. The system glue work we do most is joining one modern system to one old one, and the old one is rarely as closed as it looks once you have walked the four doors in order.
What we have built, and what we have not measured
We have built against nine systems with published APIs, and the register names them. Every legacy job is by definition one we have not built against before — that is what makes it legacy — so this page carries no claim of prior implementation and no measured figures. It carries the pattern and the published facts that constrain it.
What we would do on an engagement is spend the first hours finding out which door is open, in the order above, and telling you plainly if the answer is none — or if the honest answer is that the legacy system should be replaced rather than integrated, which is more common than integrators like to say. What not to automate covers that decision.
If you want to talk it through, start with a Leak Check. If you want to know the shape of an engagement first, the how-we-work page is the honest version.
The questions people actually ask.
01Our old system has no export. Are we stuck?
Rarely. If it prints, it can usually print to PDF, and a PDF can be read. If it emails, the mailbox is the door. If it sits on SQL Server, Access or a similar database, a read-only copy is nearly always possible. What we will not do is log in as a user and drive the screens. If that genuinely is the only way in, the honest advice is that the system has reached the end of its life, and we will tell you that rather than build something that breaks when a button moves.
02Isn’t reading the database directly faster and cheaper than all this?
Faster to start, yes. Cheaper over a year, almost never. A direct read depends on a schema the vendor never promised to keep, and a direct write bypasses every validation the application does. We build database access read-only, from a replica or nightly copy, and treat the schema as something that will change without warning. If the write path matters, it goes through the application’s own import or a vendor-supported interface, or it does not go.
03The vendor is gone. Who fixes it when it breaks?
You do, or whoever you choose to — because you own what we build. Repository access, documentation and the deployment are yours from the first increment, which is the whole point of the ownership position. For the legacy system itself, the answer is a replacement plan with a date, and an integration built so that swapping the old system out means rewriting one connector, not the whole thing.
Stop bending.
Start shipping.
Bring the one flow that keeps costing you a Tuesday afternoon. We map it live and tell you what we'd build, what we wouldn't, and what it costs.