Extracting Data From Systems That Have No API

July 8, 2026 · 7 min read · AI & Data

Key Takeaways

No API usually means three options: read the database, hijack the export feature, or scrape the screen — in that order.
Most legacy UIs sit on ordinary databases; a week of detective work beats a vendor integration quote.
The vendor's own report writer is a front door they forgot they built.
Screen scraping is brittle and slow, but it beats re-keying data by hand.
Log row counts and alert on failures; silent sync death is the real enemy.
Clean extracted data is the foundation for every copilot and agent you build later.

The screen is green. Not dark-mode green. Green-phosphor, 1987-called-and-wants-its-terminal-back green. Deb, who has dispatched trucks for this regional carrier since before their youngest driver was born, tabs through fields with the muscle memory of a concert pianist. Every load, every driver, every customer credit hold lives inside this thing. It has no API. It has no documentation. The vendor got acquired twice and the current owner answers support emails with a PDF price list for "custom integration services."

Welcome to legacy system data extraction with no API, the least glamorous and most common first job on any engagement like this. You need that data out: the new routing tool, the customer portal, the dashboard the owner keeps asking about, all of it dies without what is trapped in Deb's green screen.

Here is the direct answer: when a system has no API, legacy system data extraction with no API comes down to three realistic paths. Read the underlying database directly, hijack the vendor's own export or report feature, or scrape the screen itself. In that order of preference. Almost every trapped-data project I have shipped used one of those three, and the boring option wins far more often than the clever one.

The Legacy System Data Extraction, No API Playbook

Pick your path by asking two questions. Where does the data physically live, and what did the vendor leave lying around? Old systems are usually less sealed than they look. The vendor never built an API because nobody asked in 2004, not because they hired cryptographers.

A rough decision order that has served me well:

Direct database read. Fastest to build, easiest to schedule, most likely to be technically possible.
Scheduled export. The system's own report writer or CSV dump, automated. Slower, uglier, but vendor-blessed.
Screen scraping. Terminal emulation or OCR. Brittle, slow, and still better than re-keying data by hand, which is the actual alternative.

Notice what is not on the list: paying the vendor's integration division. Get a quote for the comedy value, by all means, but the number will usually fund your entire project twice over.

Start With the Database

Most legacy apps are a crusty UI stapled to a perfectly normal database. The green screen is often a terminal talking to something like DB2, an ancient SQL Server, or a file-based store that a modern driver can still read. Your first week of legacy system data extraction with no API is mostly detective work: what is this thing actually storing, and where?

Getting read-only access

Ask the client's IT person (or the vendor, or the guy who installed it in 2009 and still does their printers) for read-only database credentials. Frame it as reporting, not integration; vendors panic about writes and shrug about reads. I once got read access to a freight system by pointing out their own backup tool connected the same way. If the database is genuinely locked, look for the backup files. A nightly backup is a database with a bow on it.

Mapping a schema with no map

Expect tables named TBLOPR47 and columns like F013. The trick is correlation: pull up Deb's screen showing order 4471, then search the database for 4471. Do that ten times and the schema starts confessing. Budget two or three days for a mid-size system. Say the thing has 300 tables; you will care about maybe 12 of them. Document as you go, because you are the documentation now.

The CSV Export Route

When the database is truly sealed (hosted vendor, proprietary file format, contract clauses with teeth), go through the front door the vendor forgot they built: reports. Nearly every legacy system can print or export something, because 2004's customers demanded it.

The move is to find the report that contains your data, run it on a schedule, and parse the output. A typical setup:

A saved report definition that dumps orders, customers, or inventory to CSV or fixed-width text.
A scheduled task that fires it nightly at 1 a.m., often using the vendor's own batch mode.
A watched folder; when a new file lands, a small script validates and imports it.

Fixed-width "print" files look horrifying and parse beautifully. Column positions never change, which makes them more stable than some modern APIs I could name. The downside is latency: nightly means nightly. For a dispatch board that needs minute-level freshness, that is a real constraint, and it pushes you toward the database or the screen.

Screen Scraping as a Last Resort

Sometimes there is no reachable database and no usable export, and the only door is the one Deb uses. Then you scrape. Terminal emulators for mainframe-style apps can drive the green screen programmatically: send keystrokes, read fields, pretend to be a very fast, very patient employee. For GUI-era apps, UI automation tools click and read on a virtual display.

Be honest about the tradeoffs. Screen scraping is slow (seconds per record, not milliseconds), brittle (a vendor update that moves a field breaks you), and weirdly satisfying when it works. Mitigate with three habits: scrape only what changed since the last run, keep the scraper logged and screenshotted so failures are diagnosable, and isolate it behind your own clean internal API so the rest of your system never learns how ugly the plumbing is. I once kept a terminal scraper alive for two years behind such a facade; the day we finally got database access, the app never noticed the swap.

Make It Boring: Incremental Sync

However you extract, the failure mode that hurts is the silent one. The sync that stopped working six weeks ago, discovered the day someone compares two numbers in a meeting. Treat extraction like production infrastructure, because it is.

Three things make it boring:

Change detection. Track a high-water mark (an updated-at column, a record counter) and pull only what moved. Full reloads every night are how you find out the legacy system falls over under load at 2 a.m.
Row counts and checksums. Every run logs how many records came out versus last time. A 40% drop means the export broke, not that business did.
An actual alert. When the sync fails, someone gets paged or at least emailed. A dashboard tile that turns red counts. A log file nobody opens does not.

What to Do With Liberated Data

Getting the data out is the middle of the story, not the end. Once it flows into a clean store you control, the interesting work starts: feeding it to workflows, copilots, and agents that act on it. That is exactly where guardrails for business AI stop being optional, because a system reading stale or mangled legacy data will make confident decisions on garbage. It is also the foundation for things like running AI agents in production against real operational state, or bolting an AI copilot onto your ops team so Deb's thirty years of judgment gets amplified instead of replaced.

And Deb? She still gets her green screen. You are not ripping the legacy system out; you are building a quiet escape tunnel under it. The day the company finally retires the old thing, your clean data store is the migration plan already half-done. The green screen was never the enemy. The hostage situation was.

Frequently Asked Questions

Is screen scraping a legacy system legal or okay with the vendor?

Reading your own company's data from systems you license is generally fine, but check your vendor agreement for clauses about automated access. Scraping via a terminal emulator looks like a user session, which keeps you in a gray-but-common zone. When in doubt, the scheduled-export route is the most defensible because it uses the vendor's own features.

How often should you sync data from a legacy system?

Match the sync cadence to the decision it feeds. Nightly exports are fine for financial reporting and dashboards. Dispatch and inventory tools usually need 5-to-15-minute incremental pulls, which pushes you toward direct database reads. Full reloads should be rare; incremental high-water-mark syncs are kinder to old hardware.

What if the legacy schema changes after you map it?

Vendor updates do occasionally rename or restructure tables. Keep your extraction queries in one documented layer, add row-count and schema-drift checks to every run, and you will catch breakage the same night it happens instead of weeks later. In practice, truly ancient systems change very rarely.

Can you write data back into a system with no API?

Sometimes, but treat it as a separate, riskier project. Options include direct database writes (dangerous without understanding the app's integrity rules) and screen automation that mimics a user typing. Start read-only, earn trust, and only automate writes once you can test against a copy of the system.

Want the full picture? Read the complete guide to forward deployment engineers.

Read the Guide