Logistics API integration: how TMS, WMS, and carrier systems exchange data

Logistics API integration is the work of connecting the systems that already run an operation, so that one shipment exists as one record instead of four copies that drift apart. The HTTP call is the easy part. What decides whether the integration holds is three things: which system owns which field, whether every message is safe to deliver twice, and whether anything checks that the systems still agree tomorrow morning.

This article is about that layer. Transports, event delivery, idempotency, status normalization, and reconciliation, with the failure modes that show up in month four instead of in the first demo. It is not a buyer's guide to transportation management products, and we do not sell one. If you are looking at the services side instead, our logistics software development page covers what we build and for whom.

What logistics API integration actually connects

Four kinds of system, and almost all of the work sits in the seams between them. TMS integration and WMS integration are the two pairings people name most often, but neither is a single connection: each system owns a different part of the same shipment, and each has a small set of messages it is expected to send. The split below is the common one rather than a rule. Which system owns which record is a decision your project has to make explicitly, and the table is where to start arguing about it.

The same physical movement also changes name as it travels: an order in the OMS becomes a shipment in the TMS, a load to the carrier, and a consignment on the 3PL invoice. Agreeing which name maps to which is the quiet half of the work. The louder half is one rule that survives every project: exactly one system owns each record, and everybody else holds a copy that is allowed to be stale. It sounds obvious written down, and it is the thing most often left undecided. If the ERP and the WMS both believe they own on-hand quantity, you will spend the rest of the engagement writing tie-breaker rules for mismatches nobody can explain, and the operations team will keep a spreadsheet on the side because they stopped trusting both screens.

Pick the transport per counterparty, not per project

You will not get one protocol across the network, so stop designing for one. A realistic stack runs electronic data interchange with the incumbent carriers and 3PLs, REST with the newer ones, and scheduled files with whatever the warehouse happens to run.

• EDI. X12 in North America, EDIFACT elsewhere, usually over AS2 or a value added network. This is where load tendering, tender responses, shipment status messages, freight invoices, and warehouse shipping orders still live for large counterparties. On the road side the recurring set is small: 204 carries the load tender, 990 the carrier's accept or decline, 214 the shipment status updates, 210 the freight invoice, with 856 for the advance ship notice and 940 and 945 between a shipper and a warehouse. It is batch-shaped by nature, and it will not disappear because one shipper asked. Full identifiers are published in the X12 transaction set list.
• REST and JSON. Modern carrier APIs and cloud WMS or TMS products. Rates, labels, tracking subscriptions, address validation, usually behind OAuth. Faster to build against, and the layer that changes most often.
• Files over SFTP. Still the default for on-premise warehouse systems and older 3PL partners. It is the cheapest thing to agree on in a kickoff call and the most expensive thing to operate afterwards, because a file that silently arrives half-written looks exactly like a file that arrived fine.
• Event standards. Where several parties need the same visibility events rather than point-to-point feeds, GS1 EPCIS is the published option. Release 2.0 was ratified in June 2022 and, in the standard's own change list, added JSON and JSON-LD syntax alongside XML and REST bindings alongside SOAP and WSDL. Push delivery is part of the conformant query interface: a named query SHALL support subscription using HTTP callbacks, and MAY support WebSockets.

The practical consequence is an architecture rule rather than a technology choice. Define one internal event model for your own domain, then write a thin adapter per counterparty that translates into it. What you are protecting against is X12 segment names and carrier-specific field names leaking into your database, because once they do, adding the fifth carrier means touching every service instead of one folder.

Direct carrier APIs or an aggregator

Before you count carriers, decide whether you are connecting to each of them yourself. Two categories of intermediary exist: rate and label aggregators, which give you one contract and one schema across many carriers, and visibility aggregators, which normalize tracking events across modes. Both remove work you would otherwise repeat per carrier.

The trade is control for coverage. A direct connection gives you the carrier's full feature set, their own rate logic, and a support path that goes to the carrier. An aggregator gives you breadth and one integration to maintain, at the cost of a second vendor whose uptime, feature lag, and deprecation schedule now sit between you and the carrier. Our rule of thumb: go direct with the two or three carriers that carry most of your volume and where their specific services matter, and use an aggregator for the long tail where you mostly need a rate, a label, and a tracking number. The mechanics in the rest of this article apply either way, because an aggregator is itself a counterparty with its own status vocabulary and its own idea of a timestamp.

Use events where you can, and keep polling as the backstop

A webhook is a delivery attempt, not a guarantee. Your endpoint was redeploying, the carrier retried three times into a 502, and then it stopped. Nothing in your system knows that a shipment stopped producing events, because the absence of a message is not a message.

So run both. Subscribe to the events, and separately sweep every open shipment on a schedule to ask the counterparty what it thinks the current state is. Keep the sweep running after the webhooks start looking healthy, because it is the only thing that will tell you when they quietly stop. Give it a metric of its own, the number of shipments where the polled state differed from the state you already held, and alert when that number moves.

Make every message safe to send twice

At-least-once delivery is what you get in practice from carriers, queues, and your own retries. Design for it at the boundary, and you will not be fixing it in the database later.

• Idempotency keys on writes. Where the counterparty supports one, send it. Where it does not, derive a natural key from the fields that identify the event, normally shipment id plus event type plus the carrier event timestamp, and reject the duplicate at ingestion.
• Retries with backoff and a dead letter queue that has an owner. A queue nobody is assigned to is a queue that grows until someone notices the numbers are wrong.
• Two timestamps per event. Store the time the carrier says the thing happened separately from the time you received it. Then order state transitions by the first and monitor lag with the second.
• No silent overwrites. An older event that arrives late must not overwrite newer state. Compare the carrier event timestamp before you write, and log the rejection instead of dropping it.

None of this is logistics-specific, and the same thinking shows up in our own systems. Automated lead capture at Ronas IT runs on two plain rules: contacts are deduplicated by name plus source, and a lead carries an expiry date, so a new message from a known contact refreshes the existing lead while a message after the window opens a new one. In our outbound pipeline the step that writes a message and the step that delivers it are separate, and delivery counts as done only after the system reads the destination back and confirms the exact text is there. Read-back is what turns “we called the API” into “the other side has it”.

Already seeing duplicate shipments or events that arrive out of order? Send us the message flow and we will tell you where the boundary is missing.

Contact us

Normalize carrier statuses before they reach your product

Every carrier ships its own status vocabulary, and no two agree on where one state ends and the next begins. Map them all to a small canonical set on the way in: tendered, accepted, picked up, in transit, exception, delivered, plus a reason code for the exception. Keep the raw payload next to the mapped record, unchanged.

The payoff shows up in two places. Your product and your service-level calculations need one vocabulary, or every screen and every report reimplements the mapping slightly differently. And when a carrier adds a status code without telling anyone, which happens, you fix one table instead of hunting through application logic. Give the mapping an explicit unknown bucket that raises an alert rather than a default that quietly files new codes under “in transit”.

Timestamps generate more support tickets than any protocol choice. Plenty of carrier feeds send local time with no offset, so an event at 23:40 can land on either side of a date boundary depending on what you assume. Store an instant plus the location the event happened at, and do not guess the zone from the account country. Two neighbors of the same problem are worth normalizing in the same place: weight and volume units, where one counterparty sends pounds and the next kilograms, and address formats, where the same delivery point is written four ways across four systems.

Reconciliation is a feature, not a cleanup job

Integrations rarely fail loudly; they drift. Three reconciliation jobs catch most of that drift before a customer does, and they belong in the first release rather than in a later hardening phase:

1. Stock. WMS on-hand against the ERP copy, per location, on a fixed schedule.
2. Money. Planned shipments in the TMS against the carrier invoices that arrive later. Freight audit is usually the first place a broken integration turns into a number the finance team notices.
3. Silence. Shipments accepted by a carrier that have produced no tracking event within an agreed window. This is the job that finds the webhooks that stopped.

Each of the three needs an exception queue with a named owner and an aging view, not an emailed report. Without an owner the report goes unread, and after a month the mismatch count becomes a number people quote instead of a number people fix.

Plan for the carrier API changing under you

Third-party interfaces are the part of a logistics stack you do not control, and they move on their own schedule. UPS made this concrete for everyone integrated with it. It deprecated access key authentication in favor of an OAuth 2.0 security model for all APIs, and the version of its developer portal archived in May 2024 put a date on it: beginning June 3, 2024, access keys will no longer be supported for authentication to any UPS APIs. Integrations that treated authentication as settled infrastructure had a hard deadline attached to it.

We have run that class of migration ourselves. Two of the Google services behind Lainappi, a Finnish-market peer-to-peer rental app we built, were retired: the deep-linking service and the container registry. Replacing both took days, because each vendor sat behind a single module instead of being spread through the codebase. Different domain, same lesson.

Our backend standard adds a rule that matters more in logistics than almost anywhere else: tests never call third-party APIs for real. The argument is about releases rather than purity, since a vendor can change its interface, go down, or throttle its sandbox, and a passing suite is what gates deployment. We lean on integration tests over unit tests for APIs because they walk a whole scenario, and API documentation is generated from tests that pass, so the documentation cannot quietly drift away from what the API does. Checking a live carrier sandbox then belongs in a separate scheduled job that alerts on breakage, not in the suite that gates a deploy.

“The question I ask on a carrier integration is not whether it works, it is what happens the day the counterparty is slow. If the answer is that orders stop, we have built a distributed system with no buffer in it. Queue the outbound, make it safe to retry, and let the operations screen show a backlog instead of an error. A backlog is something a dispatcher can act on. A stack trace is not.”

Alexander Storozhevsky, Lead developer at Ronas IT

How we build these integrations at Ronas IT

Our logistics work sits in operational products rather than in shipper-side TMS rollouts, and it is worth being precise about which is which. ShipMe is a shipping service in Saudi Arabia that runs as a reverse auction: customers post shipment requests and transporters bid on them. We built it for four roles, customers, individual shippers, corporate shippers, and corporate managers, with native mobile apps in Swift and Kotlin, an Angular web dashboard for the corporate side, and a Laravel backend. The integration lesson from a four-role product is the same one above: the role boundaries decide the message list, and getting them wrong is expensive later. Hamperapp, a laundry and dry cleaning service in Florida, has the same shape with four user types including drivers, where the operational system computes the route a driver gets instead of somebody typing it in.

On the infrastructure side, the cloud account is the client's from the first environment we create, and so is the code. We manage infrastructure as code with Terraform and Terragrunt, so every environment is versioned and changed through review, and we default to managed cloud services because certified managed services shorten the preparation work for audits such as SOC 2, HIPAA, and GDPR. Practically that means a handover is a change of contributors, not a move of infrastructure. What we leave running after launch is deliberately unremarkable: a development environment alongside production, releases that ship without hand-holding, and error tracking the project generator wires in by default rather than someone bolting it on later.

If you want the wider picture of connecting systems that were never designed to talk to each other, our post on enterprise application integration covers the same problem outside logistics, and AI for supply chain optimization covers what you can do with the data once it stops being fragmented. The operational side of running these pipelines day to day is in automating IT operations.

What logistics API integration costs and how long it takes

Two different jobs get called the same thing, and they are priced differently. Connecting your product to an external service is our third-party API integration package, which starts at $3,000 with a timeline from 1 week. Building the API layer that other systems consume is API development, which starts at $10,000 with a timeline from 3 weeks. Most logistics projects need both, in that order of difficulty. Both figures price integration work rather than a product: if what you need is the logistics system itself and not the seams between systems you already run, that is its own tier on our pricing page, starting at $50,000 with a timeline from 3 months.

Before either, the cheapest money you can spend goes on the map of what connects to what. An analysis phase at $2,000 to $3,000 over 1 to 2 weeks produces the list of systems, the record owner for each entity, and the message inventory. That document is what stops the tie-breaker arguments described above. Ongoing operational work is priced separately: DevOps and technical advice run at $50 per hour, and a technical support plan with monitoring and incident response starts at $5,000 per month. Our backend team builds the integration layer and our DevOps engineers run the environments it lives in.

The cost driver worth planning around is the number of counterparties rather than the number of endpoints. Each new carrier or 3PL brings its own authentication, its own status vocabulary, its own sandbox behavior, and its own idea of what a timestamp means. Plan a third carrier as close to the full cost of the first, not as an increment on top of it.

When an API integration is the wrong answer

There are two situations where we say so before quoting. If there is no system of record yet, and the operation runs on shared spreadsheets, integration is not your problem: you are being asked to synchronize documents that nobody owns, and the right first step is deciding where the data lives. And if a counterparty only exchanges EDI through a value added network while you move a handful of shipments a week with them, a person using their portal is cheaper than a mapping nobody will maintain. We would rather scope that counterparty out and connect the ones that carry the volume.

What to do next

Five steps, in the order we would take them on your project.

1. Write the ownership table. One row per entity, one system named as owner. Orders, inventory by location, shipments, rates, invoices, customer master data. Circulate it and get disagreements out before anyone designs a message.
2. List the counterparties and the transport each one actually offers. Not the transport they advertise. Ask for sandbox credentials in the same email, because sandbox access is often the long pole.
3. Define the canonical status set and the mapping table. Six states and a reason code is enough to start, with an unknown bucket that alerts.
4. Specify the idempotency key for every inbound event type before you write the first handler, and decide what a late duplicate does.
5. Name an owner for each reconciliation queue. Stock, freight invoices, and silent shipments. If nobody is named, the queue is decoration.

Do those five and the build becomes ordinary engineering work. Skip them and the integration will look finished in the demo and start producing mismatches around the time real volume arrives.

Send us your systems, your carriers, and the messages you already exchange, and we will come back with an integration scope and a figure.

Get an estimate