How to integrate a TMS that has no API

The wall

Sooner or later every carrier hits it: the system you need to integrate has no API. Sometimes it’s your own TMS. More often it’s a customer’s: they run their operation on software that was built before integration was table stakes, and they are not migrating because you asked.

At that point most teams pick one of three bad options. Re-key everything by hand forever. Pitch a multi-year migration nobody wants. Or wait for the vendor’s API roadmap, which is a polite way of saying never.

There’s a fourth option: integrate anyway. Every system exposes more surface than its API docs admit. The job is picking the right surface and engineering it like you mean it.

The five surfaces, in order of preference

1. A real API

If one exists, use it, even a bad one. A limited REST endpoint with rate caps beats everything below this line. Check for partner APIs and webhook offerings that aren’t publicly documented; vendors often have more than they advertise.

2. EDI

Freight ran on EDI before APIs existed, and most TMS platforms still speak it: 204 load tenders, 990 responses, 214 status updates, 210 invoices. EDI is batchy, rigid, and very much alive. If both ends speak X12, you have a reliable, vendor-supported integration surface that nobody can deprecate out from under you. The work is in the mapping, because every trading partner’s “standard” 214 is slightly different.

3. Structured file drops

SFTP plus CSV or fixed-width files on a schedule. Unfashionable and extremely durable. Most legacy systems can export or ingest files even when they can do nothing else. Treat the file like an API contract: validate every row, version the format, and never assume yesterday’s columns.

4. The database

Some on-prem systems will give you read access to a replica. When the vendor agreement allows it, this is a clean way to get data out (never write in; you don’t own the invariants). The risk is schema drift on vendor upgrades, so isolate everything behind views you control.

5. UI automation

When there is truly nothing else, drive the application the way a person does. On Windows desktop apps that means the UI Automation tree, not screen pixels: with a library like FlaUI you address actual controls (this field, that button) so the automation survives cosmetic changes that would kill a pixel bot.

This is the surface people dismiss as fragile, and badly built, it is. Built properly it runs in production for years. We process 200+ TMW invoices a day this way for a fuel carrier, because TMW’s invoicing workflow has no API at all.

The principles that keep any of these alive

The surface matters less than the engineering around it. Five rules, regardless of layer:

• One canonical model. Translate every surface into a single internal event shape at the edge. The core never knows whether a status update arrived by API, EDI, or a file drop. New integrations become mapping work, not architecture work.
• Idempotency everywhere. Files get re-dropped, EDI gets re-sent, UI runs get retried. Every operation must be safe to repeat, or you will double-post an invoice at the worst possible moment.
• Retries with a dead letter. Things fail. The question is whether failures queue for replay and review, or vanish.
• Condition-gate the risky surfaces. For UI automation especially: evaluate each item against explicit criteria before touching it, automate what matches, and route everything else to a human unchanged. Coverage widens release by release. We wrote up why the staged rollout wins.
• Observability or it didn’t happen. Every sync, every run, every skip: logged, auditable, retryable. Integrations without an audit trail get blamed for everything and can defend themselves against nothing.

Picking the surface

Volume and latency push you up the list: real-time status at scale wants APIs or event streams. Vendor relationships push you around the middle: EDI and file drops are contractually safe almost everywhere; database access needs a yes in writing. Desperation pushes you to the bottom, and that’s fine. The bottom works when it’s engineered like production software instead of a macro.

This is the exact problem space our product Manifold lives in: one integration layer for every TMS in a fuel carrier’s stack, bridging EDI and API systems both ways. The same architecture carried a carrier’s orders and statuses to 5,000+ c-stores across systems that were never designed to talk.

The five principles aren’t aspirational. They’re what remains after years of integrations that lacked one of them and paid for it. Pick the highest surface you can get, build it like production software, and it stops mattering that the API never shipped. If you’d rather skip those years, Software Development is the practice.