Count the browser tabs open at your shipping desk right now. One for parcel rates. One for the LTL carrier's portal. One for tracking. One for the tool that prints the label. Every tab is a place where a person copies a number from one system into another.
Direct carrier API integration closes those tabs. The order line in your WMS or ERP asks the carrier for a rate, a label, and a status. The answer lands back on the same line. Nobody retypes a tracking number.
This year gave operators a reason to look at how they connect. Several carriers changed how their systems accept connections. Some shippers found out when rates quietly stopped appearing. This article covers what changed, what a direct connection does, and when renting the middle layer still makes sense.
What changed in carrier connections this year
The older connection methods are being switched off. The dates are public.
- USPS retired its Web Tools platform on January 25, 2026. The USPS Web Tools notice points developers to the new API catalog.
- FedEx moved its older Web Services to maintenance-only support on July 1, 2026. The FedEx migration guide says troubleshooting and development support for the old service ends.
- Trade coverage put the FedEx migration deadline for direct customers at June 1, and for software providers at March 31. Viya's migration summary lists both.
- UPS moved to a token-based login model starting in 2023 and has since retired its legacy access keys. ShipperHQ's roundup of carrier API changes walks through the sequence.
LTL is moving the same way. The Digital LTL Council published an electronic bill of lading standard in 2022. In August 2025 it added a preliminary freight charges standard. Transport Topics reported that it sends alerts on reweights, reclassifications, and accessorial changes before the final invoice.
The common thread is simple. Carriers now expect a modern REST connection with expiring login tokens. Old connections do not always fail loudly.
One developer's account from September describes the pattern. Stores using the retired FedEx connection simply stopped showing FedEx rates. Uptime monitors stayed green. Orders fell through to a flat backup rate. Nobody saw an error, because there was no error to see.
That is a software seam, not a people problem. The connection sat between two systems, and neither one owned it.
Batch EDI and live API calls do different jobs
EDI is not the villain here. It is a dependable way to move documents between companies. Its limit is timing.
Most EDI runs on a schedule. A file goes out, a file comes back, and the interval is minutes or hours. That suits a load tender or a freight invoice. It does not suit a packer waiting on a label.
An API call is a question with an immediate answer. Your system asks, the carrier replies, and the reply is usable in the same moment.
Here is how the two compare on the dock:
- Rates. A batch gives you a rate table loaded earlier. An API returns a live quote for this carton, this address, your contract.
- Tracking. A batch delivers status when the next file arrives. A webhook pushes each event as it happens.
- Proof of delivery. A batch waits for the cycle. An API attaches it to the order when the carrier posts it.
- Errors. A batch reports a bad address later. An API rejects it while the carton is still on the bench.
A good integration uses both. It speaks API where the carrier offers one and EDI where the carrier does not. Your team should not have to know which one answered. Our logistics and EDI glossary defines the document types if the numbers are unfamiliar.
What direct carrier API integration puts on the order line
The point is to bring the carrier's answers into the system your people already use. Five things move.
- Rate shopping. Every eligible carrier is quoted against your negotiated rates and routing rules. The choice is recorded on the order.
- Labels. The label comes back as ZPL or PDF and prints at the station. The tracking number writes itself to the shipment.
- Documents. Bills of lading, customs forms, and commercial invoices are generated from order data, not typed again.
- Tracking events. Status and revised arrival dates post to the order as the carrier reports them.
- Exception alerts. A hold, a failed delivery, or a wrong-city scan lands in a queue with an owner.
The last item matters most. Software watches every shipment so people do not have to. Your customer service lead then spends the morning on the six shipments that need a decision, not the six hundred that do not.
We saw this on an inbound freight visibility project. Four carriers fed status onto the open shipment record. Carrier holds and misrouted freight surfaced in their own queues. People stopped pasting tracking numbers into carrier websites.
Renting the layer versus owning it
A multi-carrier shipping platform is a fair choice for many operations. It connects quickly. Someone else keeps up with carrier changes. If your volume is modest and your needs are standard, it may be all you need.
The trade-offs appear as you grow:
- The fee usually scales with label count. Your busiest month is your most expensive month.
- Your shipping flow lives in another company's product. Their roadmap decides what you can change.
- The data sits in their account. Reporting across carriers means another export.
- Leaving means rebuilding the connection, so the decision gets postponed.
Owning the layer changes each of those. The code runs in your account. It is plain code in a common language, and you own it outright. There is no meter on labels from us. Any competent developer can maintain it.
Ownership also has a cost, and it is worth saying plainly. The maintenance is yours too. This year showed that carriers do change their interfaces. An owned layer needs someone watching it, either on your team or under a support agreement.
The honest test is arithmetic and control. Compare a per-label fee over three years against a one-time build plus upkeep. Then ask how often the rented tool has stopped you from doing something a customer asked for.
What a direct integration has to get right
A carrier API is easy to call once. Running it all day on a dock is the real work. Four details separate a demo from a system.
Tokens expire. Modern carrier logins issue a token that lasts about an hour. The integration must cache it and renew it before it lapses. Requesting a new token on every call gets you blocked.
Rate limits are real. The FedEx rate limit documentation caps each project at 1,400 transactions per 10 seconds. An address that breaks the login thresholds is penalized for 10 minutes. A wave release that fires every label at once can hit that wall.
Outages happen. One carrier going quiet should not stop the dock. Requests need queues, retries, and a fallback carrier rule your team has approved.
Silence is a failure. The September shutdown story is the lesson. Monitor for missing rates and quiet tracking feeds, not just error codes.
The printer is part of the path too. A label that arrives instantly still has to print. On an industrial label printing project, eight printers kept locking up under burst volume. The cause was how jobs were sent, not the hardware. Fixing the transport fixed the dock.
None of this requires replacing your WMS or ERP. The layer sits beside the system you run and reads and writes through its existing doors. If you ship FedEx, the 2027 rate increase checklist shows where stale rates hide in the same seams.
Run a tab count this week
You can size the problem in an hour. Stand at one pack station and watch 20 shipments go out.
- Count the browser tabs and separate programs touched per shipment.
- Count every copy and paste of a tracking number, weight, or address.
- List each carrier and how it connects: portal, rented platform, batch EDI, or direct API.
- For each connection, write down who would fix it if it stopped tomorrow.
- Time how long a delivery status takes to reach your own system.
- Ask what happens when a rate request returns nothing. Is there an alert, or a silent fallback?
Then read your list back. Any carrier connected by portal is a re-keying point. Any connection with no named owner is a risk. Any silent fallback is a billing surprise waiting for its month.
If the list is short, you are in good shape. If it is long, you now have a scope.
Stone Age Software builds carrier integration on top of the WMS or ERP you already run. You own the code. The work is fixed price, quoted up front. Tell us what's broken. A sentence or two is plenty.
