Between 2023 and 2026 all three major US parcel carriers changed how software connects to them. UPS replaced its access keys with OAuth 2.0, USPS retired its long-running Web Tools APIs, and FedEx set a deadline for moving from its legacy Web Services to REST APIs. Each change is reasonable on its own; together they mean a shipping plugin installed a few years ago may have stopped returning rates or printing labels with little warning. This guide sums up what changed and walks through a carrier API migration checklist for online stores.
What changed at each carrier
| Carrier | Old connection | Current connection | Key date |
|---|---|---|---|
| UPS | An access key sent with each request | REST APIs with UPS OAuth tokens, issued to an app created in the UPS developer portal | Access keys stopped being accepted in 2024 |
| USPS | Web Tools APIs (XML) with a user ID | The new USPS APIs on the USPS developer portal, using OAuth 2.0 | USPS states the Web Tools platform was retired on January 25, 2026 |
| FedEx | FedEx Web Services (SOAP/WSDL) | The FedEx REST API, with OAuth credentials from the FedEx developer portal | FedEx asked direct customers to complete migration by June 1, 2026 |
The official sources are the UPS OAuth migration guide, the USPS APIs developer portal and FedEx's migration announcement. The USPS Web Tools retirement affects more than rates and labels: address validation, tracking and delivery standards moved to the new platform as well.
Signs your shipping plugin stopped working
Failures are not always loud. Watch for these:
- Checkout offers only a flat-rate fallback, or shows "no shipping methods available" for addresses that used to work.
- Label creation fails in the admin panel, or labels print for one carrier and not another.
- Tracking numbers stop updating, or shipped emails go out without a tracking link.
- Error logs show authentication errors (401 or 403 responses) or failed connections to carrier addresses.
The quiet version is the most expensive: a fallback rate that looks normal but sits far below what the carrier bills. When a shipping plugin stopped working this way, the loss shows up weeks later on the carrier invoice rather than at checkout.
A carrier API migration checklist
- List every system that talks to a carrier: the store's shipping extension, label software, the ERP or warehouse system, marketplace tools and any custom scripts. Old integrations tend to hide in the last two.
- Create developer accounts and apps under the business's own carrier accounts, not a developer's personal login, and record who owns them.
- Store credentials on the server, outside the code repository, and make sure the integration requests and refreshes its access tokens itself instead of relying on a key pasted in once.
- Update or replace the connector. A current shipping connector for FedEx and UPS may be a new version of your plugin, a different extension or a multi-carrier shipping platform. Confirm that it calls the new APIs rather than a compatibility layer on the old ones.
- Test in the carriers' sandbox environments, then compare live quotes with your negotiated account rates and a few recent invoices.
- Check labels and paperwork: thermal (ZPL) or PDF format, customs data for international parcels, return labels.
- Re-test address validation, including business versus residential classification, which changes the price.
Our shipping API integration and logistics automation work covers these steps, from securing the carrier credentials to test shipments in a staging environment before real packages go out.
Keeping it working: a simple shipping API monitor
Carrier interfaces will keep changing, so build in an early warning. A basic shipping API monitor requests a rate for a known address and package every hour or so and alerts someone when the request fails or the price changes sharply. Add alerts on the rate of failed label requests, a calendar reminder for any credential that expires, and a subscription to each carrier's developer announcements. None of this is complicated, and it turns the next retirement notice into a planned task instead of a Monday morning surprise.
Direct integration or a shipping platform?
Connecting the store straight to each carrier gives the most control and no per-label platform charges, but every carrier change lands on you. Multi-carrier platforms such as ShipStation, Shippo or EasyPost absorb those changes and add batch labels and automation rules, at the cost of a subscription or per-label fee and one more system in the chain. Stores with one carrier and simple rules often do well with a direct connection; stores shipping through several carriers or from several locations usually benefit from a platform. Either way, good shipping API integration services should leave you with documented credentials, logs and a monitor, not just a working checkout.
Frequently asked questions: carrier api migration
Do we need a new carrier account to use the new APIs?
No. You keep your shipping account and create an app in the carrier's developer portal that is linked to it. The app's credentials are what the integration uses.
Will our negotiated rates still show at checkout?
Only if rate requests are made with your own account. A connector that uses generic credentials or list rates will show published prices instead.
We missed a deadline. What now?
Find which systems still call the old interfaces, switch checkout to a safe fixed rate if live rates are failing, and fix the connection that prints labels first, because that is what stops orders from shipping. Then migrate the rest.
Rates missing at checkout, or labels failing after a carrier change? Our shipping API integration service connects stores to FedEx, UPS, USPS and shipping platforms, with real-time rates, batch labels and tracking written back to the store. If stock and orders also need to reach an ERP, see ERP and PIM integration. Contact us with your platform, your carriers and the plugin you use today, and we can review what needs to change.
