FedEx API Migration: What Shippers and Software Providers Need to Do Before June 2026

On 30 January 2026, FedEx issued a clear deadline: all integrations must migrate from FedEx Web Services to FedEx REST APIs. Compatible Providers (software vendors, TMS platforms, shipping tools) must complete their upgrades by 31 March 2026. End customers must complete migration by 1 June 2026.

If you ship with FedEx — or if your shipping software connects to FedEx — this isn’t optional. The legacy SOAP/XML APIs are being retired, and integrations that haven’t migrated will eventually stop working.

What you’ll learn:

• What’s changing
• The migration timeline
• What’s different technically
• Who needs to do what
• What shippers should do

What’s changing

FedEx has operated two API platforms in parallel for several years:

FedEx Web Services — the legacy platform, built on SOAP (Simple Object Access Protocol) with XML-based WSDL schemas. This is how most FedEx integrations have worked for over a decade: download a WSDL file, generate client code, send XML requests, parse XML responses. Authentication used static credentials — a meter number, authentication key, password, and account number.

FedEx REST APIs — the modern platform, available through the FedEx Developer Portal. RESTful architecture, JSON payloads, OAuth 2.0 token-based authentication. This is where all new features and capabilities are being developed.

FedEx Web Services has been in “development containment” for some time — meaning no new features are being added. But now FedEx has set firm deadlines for the full retirement. The legacy platform will no longer be supported after the migration window closes.

This mirrors what other major carriers have done. UPS completed a similar migration from SOAP/XML to REST/JSON APIs in 2024. DHL adopted REST architecture earlier. The entire carrier integration landscape is standardising on REST and OAuth 2.0.

The migration timeline

The two-tier deadline is deliberate. FedEx wants software providers — the companies whose platforms handle FedEx shipping for thousands of customers — to migrate first. That gives them two months to validate, test, and roll out updates before the customer deadline hits.

If you use a FedEx Compatible Provider (a TMS, shipping platform, or e-commerce tool that integrates with FedEx on your behalf), your provider manages the technical migration. You shouldn’t need to rewrite code yourself. But you will need to coordinate with them on timing, credentials, and any multi-factor authentication (MFA) requirements.

If you integrate directly with FedEx — your own development team built and maintains the connection — you are responsible for the migration. Work with your FedEx representative or the Developer Portal’s support resources.

What’s different technically

This isn’t a minor version bump. The migration is a fundamental architectural change:

The biggest change is authentication. The old system used static credentials that never expired — set them once and forget. The new system uses OAuth 2.0: your application requests a bearer token using an API key and secret, and that token expires after 60 minutes. Your integration must handle token caching, expiry detection, and automatic renewal. It’s more secure, but it’s a meaningful architectural change for applications that assumed credentials were permanent.

For Compatible Providers (now called “Integrator Providers” on the new platform), authentication is more complex. They use a csp_credentials grant type with additional child_key and child_secret parameters to manage access on behalf of their customers’ FedEx accounts.

Who needs to do what

If you use a TMS or shipping platform

Your provider handles the technical migration. But don’t assume it’s entirely hands-off:

• Confirm your provider’s timeline. Have they started? Will they meet the 31 March deadline? Ask directly.
• Check credential requirements. The new platform may require you to create an account on the FedEx Developer Portal or provide new credentials to your provider.
• Test after the switch. When your provider rolls out the REST API integration, verify that your shipping workflows — label generation, rate requests, tracking, pickups — still work as expected.
• Watch for MFA. FedEx’s new Integrator Program requires multi-factor authentication in end-customer registration flows. Your provider will guide you through this if it applies.

If you integrate directly

This is a significant development project:

• Create an organisation on the FedEx Developer Portal and set up a project with test and production API keys.
• Rewrite your API calls. Every request and response changes from XML to JSON. Field names, data structures, and nesting are all different. This is not a find-and-replace operation.
• Implement OAuth 2.0 token management with proper caching and automatic renewal.
• Complete label validation. FedEx requires Ship API users to submit test labels (scanned at 600 DPI minimum) for validation before going live.
• Handle rate limiting. Implement proper retry logic for HTTP 429 responses (too many requests).
• Note the European differences. European customers have a different validation process that requires guidance from a FedEx Customer Technology representative — it’s not fully self-service like the US/Canada flow.

If you’re a European shipper

Be aware of some limitations specific to Europe:

• No webhook support — FedEx’s Advanced Integrated Visibility (push-based tracking via webhooks) is currently available for US-based accounts only. European shippers must continue polling the Track API.
• Validation is representative-assisted — unlike US/Canadian customers who can self-serve through the Developer Portal, European validation requires coordination with your FedEx CT representative.
• TNT legacy systems — if you previously used TNT Express (acquired by FedEx in 2016), you may face a double migration: TNT systems to FedEx systems, and then FedEx SOAP to FedEx REST.

What shippers should do

Whether the migration is handled by your provider or your own team, here’s how to prepare:

1. Identify your integration type — Do you use a TMS or shipping platform that connects to FedEx for you (Compatible Provider), or does your team maintain a direct API integration? This determines whether you’re coordinating or building.

2. Contact your provider now — If you use a Compatible Provider, don’t wait until May. Contact them today and ask: are you migrating to FedEx REST APIs, what is your timeline, and what do you need from us? The provider deadline is 31 March, but the customer rollout and testing window is tight.

3. Check your FedEx Developer Portal access — Even if your provider handles the integration, you may need an account on the FedEx Developer Portal. Create one now if you haven’t already. Understand the new credential model so you’re not scrambling at deadline.

4. Plan for testing — After the migration, validate your critical FedEx workflows: label generation, rate quotes, tracking, address validation, pickup scheduling. Don’t assume everything works because your provider said it would. Verify with real shipments in the test environment.

5. Use this as a carrier integration audit — FedEx isn’t the only carrier modernising its APIs. UPS went through the same transition. If your shipping operations depend on legacy API integrations with multiple carriers, this is a good moment to assess your overall integration health. A TMS that abstracts carrier-specific API changes behind a single interface reduces the impact of these migrations — you update once, not for every carrier.

The FedEx API migration is a technical change with a hard deadline. For most shippers using a TMS or shipping platform, the impact should be manageable — your provider does the heavy lifting. But “manageable” only applies if you start the conversation now, not in May when the deadline is two weeks away.

Sources: FedEx — Migrate to FedEx APIs (30 Jan 2026), FedEx Developer Portal, FedEx — Web Services development containment notice.

Johan de Grijff, Commercial Director

published on: 1-2-2026

Prev

FedEx-Led Consortium Bids €7.8 Billion for InPost: What It Means for European Parcel Logistics

Next

CountEmissionsEU: What Shippers Need from Their TMS to Comply