Automation agencies integrate client systems that have no API in four ways. They read the emails and PDFs the system already sends or receives, they use the file exports and imports it already supports, they read paper and scanned documents with OCR (optical character recognition), and, when nothing else works, they drive the system's own screens with browser automation. Which route fits depends on where the data enters and leaves the system. Each route also breaks in its own way.
This guide is for operations leaders whose ERP, agency management system or supplier portal has no usable API (application programming interface, the route software uses to exchange data with other software). Most automation tools assume one, so these systems tend to stay manual. The four routes below work without one.
We build these integrations at ATI Lab. Our shipping and logistics automation reads orders out of ERPs that have no API and books them with couriers that do. Our insurance broker builds write call records into Applied Epic, EZLynx or another AMS through browser automation where the API is missing. In accounting, the same layer posts to QuickBooks and Xero through their APIs and to portals that have none through the screens. Where a figure below is ours, it is published on atilab.io and linked.
What are the four ways to automate a system with no API?
The four routes differ in where they touch the system and in what tends to break them. The table puts them side by side.
| Route | Use it when | Example from our work | What usually breaks it | The signal that catches it |
|---|---|---|---|---|
| Email and PDF intake | The work arrives as emails or attachments that a person retypes | Shipment requests read from email and turned into labels and carrier bookings | A new sender format, a missing field, a reply sent off-thread | Rising share of items sent to the exception queue |
| File exports and imports | The system can export or import a CSV or spreadsheet, even if nobody schedules it | Asking a carrier for a scheduled export before anyone scrapes their portal | Renamed or reordered columns, an export that silently stops running | File missing at the expected time; column check fails |
| OCR on documents | The data starts on paper or in scans | Fleet travel sheets read on a phone and synced to fleet systems | Poor scans, handwriting, a new form layout | Low-confidence fields routed to a person |
| Browser automation | The only way in or out is the screens your staff use | Reading ERP orders and writing tracking back; AMS write-back for brokers | A page redesign, a login change, a slow or timed-out page | Failed runs logged with the step that failed |
The order matters. Work through the routes from top to bottom and use browser automation only when the first three can't reach the data. An email inbox and a file export rarely change without notice. A vendor's screens can change in any release, and the automation finds out when it fails.
How do automation agencies handle client systems with no API?
An agency handles a system with no API by mapping where the data enters and leaves it, choosing the least fragile route for each side, and running the new flow alongside the old one until the outputs match. The input and the output often take different routes, so one workflow can combine two of the four.
Our shipping builds show how this mixes. Orders come out of the ERP through browser automation because the ERP has no API. Each courier is called through its own API where it has one, and through its portal where it doesn't. Tracking numbers go back into the ERP through the screens again. Nobody retypes anything, and the ERP stays.
The steps that make a no-API build hold up:
- Map the flow as staff run it. Every screen, field, file and email between the request arriving and the work being done, including the workarounds nobody wrote down.
- Ask for the easy route first. Check whether the vendor offers an export, an import template or an API on another plan. Asking a carrier or software vendor for a scheduled export often costs less than building and maintaining a screen integration.
- Build with a person approving outputs. In the pilot, a person checks each item before it is written into the system.
- Run old and new in parallel. The "mirror" approach from a BCG biopharma case, which our logistics page cites, keeps the manual process running until the automated outputs match it. Then switch over.
- Hand uncertain items to a person. Anything the automation can't validate goes to an exception queue with the fields pre-filled.
How does email and PDF intake automation work?
Email and PDF intake automation reads each incoming message and its attachments, pulls out the fields a person used to retype, checks them against your rules, and writes them into the target system. The system with no API never has to accept a connection on the input side, because the input is the inbox your team already uses.
Our shipment intake build is the clearest example. Requests arrived as free-text emails with attachments in inconsistent formats, and staff retyped them into several tools. The automation now reads each email, validates the details and creates the labels and carrier bookings. The published result is 95% less manual work on that workflow and zero monthly entry errors. The operations team's interface didn't change, since everything still arrives by email.
The weak spot is variety. A new customer with a new template, a missing reference number or a reply sent in a different thread can each defeat a rule. Those items should land in a person's queue before anything reaches the ERP. If the share of items going to that queue rises week on week, a new input format is the usual cause.
When is browser automation the right choice for a legacy system?
Browser automation is the right choice when the only way to read or write the data is through the screens your staff use, and when the volume is high enough to justify maintaining the integration. It logs in as a user, opens the same pages, and reads or fills the same fields a person would.
For insurance brokers, that means driving the same Applied Epic or EZLynx screens a customer service rep (CSR) uses, with every action logged. For logistics, it means reading orders out of an ERP and writing tracking numbers back.
It is also the most fragile route. A screen integration breaks when the vendor moves a button, renames a field, adds a login step or slows a page down. Our guide to which workflows to automate first warns against making it a company's first project for that reason. If you use it, treat it as a real integration with an owner, logging of the step that failed, and someone paid to fix it when a release changes the screens. A one-off script nobody maintains will fail quietly.
Can you automate with file exports instead of an API?
Yes. Many systems without an API can still export reports or import a spreadsheet, and a scheduled file exchange is often the cheapest and most stable route. The automation picks up the export, does the work and drops an import file, or writes the results somewhere a person loads them in one step.
Look for this before anything else. Check the reports menu, the admin settings and the vendor's import templates, and ask the vendor or carrier whether they can send a scheduled export. Our insurance broker automation guide makes the same point about carrier data: asking for an export can cost less than scraping a portal.
Files fail in two ways. The export stops running, or someone changes its columns. Check that the file arrived on time and that its columns match before processing it, and alert a person if either check fails.
When do you need OCR?
You need OCR when the data starts on paper, in a scan or in a photographed document, so there is nothing digital to read until the text is extracted. After extraction, the fields are validated and passed on like any other input.
One of our builds replaced paper travel sheets in a fleet operation. A mobile OCR flow reads each sheet, validates the fields and syncs them to the fleet systems. Processing time fell 85% and document loss reached zero, as published in our case studies. That result came from high-volume, low-variance documents. Handwriting, poor scans and many form variants lower the ceiling, so set a confidence threshold and route anything below it to a person.
What AI automation can a company with no IT team and no integration budget deploy in weeks?
A company with no IT team and no integration budget can realistically deploy one narrow intake workflow, such as reading inbound emails or PDFs and writing the details into a system it already uses, with the provider running the monitoring and the exception queue. At ATI Lab a first workflow typically goes live in 6 to 12 weeks, including a pilot where a person approves every output.
Three things make that possible without an IT team:
- Start where the data is already outside the system. With email and PDF intake, your team keeps receiving the same emails and nothing changes on the input side. Only the write into the target system needs a route, and a file import is the simplest one if the system has it.
- Buy the operation along with the build. Someone has to watch the exception queue, fix a broken step after a vendor update and tune the rules monthly. With no IT team, that has to be the provider. Our AI automation services include that managed operation.
- Name one internal owner. You don't need engineers. You need one person who knows the process, reviews exceptions and signs off on the pilot.
Be careful with "no integration budget". Avoiding an API project doesn't make the integration free. With a no-API route, the integration work moves into the build and into ongoing maintenance, especially for browser automation. Ask any provider what happens, and who pays, when the vendor changes its screens. Our AI agent cost guide covers how build and running costs add up.
When should you not automate a system with no API?
Skip or delay it in four cases:
- The vendor offers an API or export on a higher plan, and the upgrade costs less than building and maintaining a screen integration.
- The system is being replaced in the next few months. Automate on the new one.
- The volume is low. If a task happens a few times a week, a screen integration's maintenance can outweigh the time it saves. Count volume, minutes per item and error rate for two weeks before deciding.
- The system's terms forbid automated access. Check the licence or portal terms before building, especially for third-party portals you don't own.
Frequently asked questions
Is browser automation the same as RPA?
Browser automation is one form of RPA (robotic process automation), the practice of software operating an application's interface the way a person does. Older RPA follows fixed scripted steps. AI adds the ability to read unstructured inputs such as emails and to make bounded decisions within your rules, sending anything uncertain to a person.
Do we need to replace our legacy system to automate it?
No. Every route in this guide works on top of the systems you already run. In the production builds on our case-study page, the CRM, ERP, TMS and email all stayed in place.
How long does it take to automate a system with no API?
At ATI Lab a first deployment typically takes 6 to 12 weeks. That covers mapping the flow, building, a pilot with a person approving outputs, and a parallel run before switch-over.
What happens when the system's screens change?
A well-run integration notices on the first failed run, logs which step failed and routes the affected items to a person, so nothing is written incorrectly. Someone then updates the automation to match the new screen. Agree before launch who does that and how fast.
Can AI read scanned invoices and write them into our ERP without an API?
Yes, by combining two routes. OCR reads the scanned invoice and extracts the fields, a validation step checks them against the vendor record and purchase order, and browser automation or a file import writes them into the ERP. Our accounting automation follows this pattern for accounts payable, with staff approving each reconciliation before it is posted.
Written by the ATI implementation team. Routes, examples and figures come from ATI Lab's published solution pages and case studies on atilab.io. AI assistance was used in research and drafting; a human owns every claim and recommendation in it.