FedEx has retired its legacy Web Services (SOAP) API in favor of the modern REST APIs. If your store’s FedEx rates or labels stopped working in 2026, this is the most likely reason — and this page walks you through exactly what to do.

​
What is retiring

FedEx announced that its legacy Web Services (SOAP) is in maintenance-only support since July 1, 2026 — no future enhancements — and that the SOAP test environment is disabled as of December 31, 2026. New development is all on the REST APIs. The official timeline is published on the FedEx Developer announcements page. In practice this means:
  • integrations that still talk SOAP to FedEx keep working less and less reliably,
  • sandbox (test) SOAP access is already gone for new testing, and
  • every store should be on a REST-based integration.
The dates above come from FedEx’s own developer announcements. For changes after December 2026, check that page — FedEx controls the timeline, not plugin authors.

​
Is my store affected?

Your store is affected if it connects to FedEx through a plugin or custom code built on the old Web Services. The typical symptoms:
  • FedEx rates vanish at checkout — other shipping methods still show, but FedEx options are gone. (This has other causes too; the full checklist is in FedEx rates not showing at checkout.)
  • Label creation fails with errors mentioning SOAP, WSDL, XML parsing, or RateService/ShipService (SOAP service names — the REST endpoints use paths like /rate/v1/rates/quotes).
  • Your FedEx developer account shows an old “Web Services” project and you were never issued REST keys.
If you are unsure which technology your current plugin uses, ask its developer one question: does it call https://apis.fedex.com (REST) or a SOAP/WSDL endpoint?

​
Why this plugin is not affected

TeamzLab FedEx Shipping was built REST-native from the first release. Every request it makes — rates, labels, tracking, pickups, returns, international paperwork — goes to FedEx’s REST endpoints (https://apis-sandbox.fedex.com for testing, https://apis.fedex.com for production). There is no SOAP code in the plugin, so the retirement does not break anything you have already set up with it. If you are installing it fresh, you can skip the migration entirely and go straight to Connecting FedEx credentials.

​
Migrate to REST step by step

If you are switching from an older SOAP-based setup, the key fact is: REST uses new credentials. Nothing from your SOAP setup carries over — not the keys, not the configuration. Here is the full path:
1

Create REST credentials on the FedEx developer portal

Log in at developer.fedex.com, create a project, and copy the API key (client ID) and secret key (client secret) for the test environment. You need one pair for shipping/rates and one for tracking — the plugin asks for them on separate tabs. The detailed walk-through with screenshots is on Connecting FedEx credentials.
2

Add the FedEx Shipping method to a zone

In WooCommerce, add the Fedex Shipping method to your shipping zone so the plugin starts quoting. See Adding FedEx rates to your store.
3

Test in sandbox

Place a test order with a sandbox destination and confirm live rates appear and a test label creates. Sandbox keys and test rates are free.
4

Get production access and switch over

Production REST access requires FedEx to approve your real FedEx account number — allow a few business days. Then switch the plugin’s environment from sandbox to production on the Account tab. The full go-live checklist is on Going live: from sandbox to production.
5

Retire the old integration

Deactivate the old SOAP-based plugin once the new one is creating labels and receiving tracking updates. Do not run both quoting FedEx rates in the same zone — customers would see duplicates.

​
Your old SOAP credentials will not work

This is the single most common migration mistake: pasting the old Web Services key (or a key from another plugin) into a REST integration. REST and SOAP credentials are different projects on the FedEx developer portal and are not interchangeable. If you see authentication errors right after migrating, create fresh REST keys — do not reuse anything from the SOAP project. If keys are correct but rates still do not appear, work through FedEx rates not showing at checkout — it covers zones, addresses, service filters, and every other documented cause.

​
Verify quietly with staging mode (advanced)

The plugin ships a diagnostic toggle for exactly this kind of transition. With staging mode on, the plugin records the FedEx rate requests it would make into a rolling log so you can inspect them — checkout behavior is not changed. It has no admin screen; it is controlled with WP-CLI or similar:
The log is capped at 100 entries and lives in your database — always turn the toggle off afterwards. This is a developer-facing tool; store owners migrating from another plugin can simply watch the checkout and the Troubleshooting guide instead.

​
FAQ

No. Your FedEx shipping account number stays the same. Only the API credentials (client ID and secret) are new, because REST is a different API on FedEx’s developer portal.
FedEx does not charge for API access itself. You need a FedEx shipping account, and production access requires FedEx’s approval of that account. Test/sandbox access is free.
Tracking data from the old integration stays wherever that plugin stored it. The new plugin begins recording tracking events for shipments it creates — it cannot import the old plugin’s history.
FedEx controls the timeline, and the official announcements state the SOAP test environment is already scheduled to be disabled. A store that does nothing is betting on how long FedEx keeps the production SOAP lights on. Migrating removes the risk.