Carrier API Deprecation Windows: 6 Vendors Measured

FedEx promises two years. GLS promises nothing. USPS gave sixteen months and then delivered zero grace period on the day itself. If you build carrier middleware, the carrier API deprecation notice period is not a footnote in a changelog — it is the number that decides how much slack your adapter layer needs. We pulled the published deprecation and sunset dates for FedEx, UPS, DHL, USPS, PostNL and GLS and measured the actual gap in each case. No averages across carriers who don't publish a schedule, no interpolation. Where a figure wasn't public, it's marked "Not published."

Why the notice window is an architecture input, not a legal footnote

Every compatibility window you build — contract tests, feature flags, parallel-run adapters — has to span at least the shortest notice period you'll realistically encounter. Design for the carrier with the generous two-year runway and you'll get blindsided by the one that gives you six weeks. The number you need isn't "what's typical." It's the worst case you can actually document.

Method — what counts, what doesn't

Data was pulled directly from each vendor's own developer portal, changelog, or terms of use between October 2026 and the time of writing. The metric is simple: calendar days between a dated, public deprecation notice and the dated, enforced sunset or shutdown. Two categories of information are kept separate on purpose:

• Per-API deprecation schedules — dated entries on a changelog or deprecation table, specific to one endpoint or service version.
• General contractual notice clauses — blanket terms-of-use language (e.g. "30 days' notice of material changes") that apply to the whole portal, not a specific API's sunset.

These answer different questions. A 30-day contractual clause tells you the legal minimum a vendor owes you before changing terms. It says nothing about how much runway you'll get before a specific SOAP endpoint stops responding. Where only the contractual clause exists and no per-API schedule has been published, that's recorded as "Not published" for the specific-API column rather than treated as equivalent.

The data table

Snapshot accurate as of 26 October 2026. Several entries (DHL's Postnumber sunset, PostNL's August 2026 cutover) are forward-looking commitments rather than completed events.

A few of these are worth a second look before you treat them as clean numbers. FedEx plans on releasing fewer major versions and deprecating a major version two years from the release of the newer major version, illustrated with a 2020 release of V1.0 and a 2021 release of V2.0 resulting in V1.0 being deprecated in 2023 — that's a documented policy, not a per-API date, which is why it sits apart from the others.

FedEx's SOAP retirement is messier than it looks. FedEx's 2022 announcement states that on August 18, 2022 FedEx Web Services SOAP WSDLs were placed into development containment, with Tracking, Address Validation and Validate Postal Codes WSDLs effective May 15, 2024 for retirement. Several resellers and plugin vendors logged the actual cutover closer to August 31, 2024, when FedEx began disabling the same Tracking, Address Validation, and Validate Postal Codes WSDLs. Two FedEx-adjacent sources, two different enforcement dates for the same WSDLs — that inconsistency is itself a data point about how carrier comms travel through the integrator ecosystem.

UPS moved its own goalposts. Early guidance and several third-party integration notes quote access keys no longer being supported for authentication beginning June 3, 2024, but the UPS-hosted notice linked from Drupal's own tracker later states beginning August 5, 2024, access keys will no longer be supported for authentication. The sunset process itself began June 5, 2023, so depending which deadline you trust, the real window was either 12 or 14 months.

DHL's Parcel DE product line is the only one in this set that behaves like a genuine engineering deprecation table rather than a one-off announcement. The published schedule lists GKV 1.x (SOAP) as Retired, with a deprecation date of 01.11.2023 and a sunset date of 31.05.2024, and a separate row shows Parcel DE Shipping V1 (Pilot) retired with deprecation 01.01.2024 and sunset 30.09.2024. The Postnumber cig.dhl.de (SOAP) API carries a deprecation date of 01.02.2024 and a sunset date of 30.09.2025, and the old Returns API via cig.dhl.de is listed as Retired with deprecation 01.08.2025 and sunset 31.05.2026. That spread — 7 to 20 months across four products on the same portal — tells you DHL's own internal practice varies more than any single number suggests.

DHL Express ran the shortest real migration in this set. Starting April 21, 2025, DHL Express transitioned from the legacy XML API to the new REST API, with the XML API fully deprecated on June 3, 2025 for Non-Enterprise customers. Six weeks, start to full cutoff. Compare that to DHL's own baseline promise: DHL reserves the right to amend its Terms of Use or Services Specifics to reflect changes in law, the Developer Portal or its systems, and commits to informing customers of material changes with prior notice of 30 days on the Developer Portal or via email. The contractual floor is 30 days. The actual Express migration gave integrators roughly double that, but nowhere near the multi-month runway DHL gives its Parcel DE customers.

USPS gave a long runway, then no landing strip. USPS announced the deprecation in Q3 2024 and ran the v3 REST API in parallel through 2025 — giving integrators roughly a year — before the legacy endpoints went dark on January 25, 2026 with no grace period. USPS's own documentation still states, months after the fact, that the platform was retired on January 25, 2026 and that availability may be degraded or interrupted at any time.

GLS gives you the least to work with contractually. GLS ITS reserves the right to modify the Developer Portal from time to time as deemed necessary, and will notify users of any material changes on the Developer Portal or by email, with such changes taking effect immediately upon notification. There is no per-API deprecation table on the GLS developer portal comparable to DHL's — hence "Not published" in that cell.

What the spread tells you

Three tiers emerge. FedEx documents a multi-year policy at the major-version level. DHL publishes genuine months-scale schedules per product, with real variation between 7 and 20 months depending on which Parcel DE API you're on. GLS and the PostNL changelog entries operate on a discretionary or short-notice basis, with GLS offering zero contractually guaranteed days for API-level changes.

USPS is a separate pattern worth naming on its own: a long runway followed by a hard cliff. A carrier that gives you sixteen months of parallel running isn't necessarily safer than one that gives you six weeks, if the long-runway carrier offers no grace period at the actual cutover. Build your monitoring to catch the day of enforcement, not just the day of announcement.

Two IETF specifications exist precisely to make this machine-readable instead of buried in prose changelogs: the Sunset HTTP header field and its successor, the Deprecation HTTP header field. Neither carrier in this set appears to expose these as response headers today, which is why this whole exercise still requires a human reading developer portals rather than a synthetic monitor parsing a header.

Designing for the worst-documented carrier, not the best

Treat the shortest observed window in your own stack — six weeks, per DHL Express's non-enterprise cutover — as your internal SLA for swapping an adapter, regardless of which carrier you're integrating today. In practice that means:

• Automated polling of each carrier's changelog or developer-portal deprecation page, not reliance on inbound email.
• Contract tests pinned to explicit version headers or URI paths, so a silent schema change fails a build rather than a production shipment.
• Feature-flagged adapter swaps that let you run the old and new integration side by side during the notice window, however long it turns out to be.
• Sandbox canaries that fail loudly on schema drift, rather than waiting for a production label to bounce.

Multi-carrier platforms such as nShift, EasyPost, ShipEngine, Sendcloud, Shippo and Cargoson exist specifically to absorb this kind of churn behind a stable internal contract. That's the abstraction layer doing its job — it is not a reason to skip internal versioning discipline, because the platform still has to absorb the same six-week DHL Express window or the same zero-day GLS clause somewhere in its own adapter code.

Limits of this data set

Only six carriers are covered here, and within them only the shipping, label and tracking products that publish dated schedules. Address-validation and B2B EDI products may run on entirely different clocks that weren't checked. GLS Netherlands and DPD had no public per-API sunset schedule comparable to DHL's at the time of writing — marked "Not published" rather than inferred from general contract language. Figures for DHL Parcel DE's Postnumber sunset and PostNL's August 2026 cutover are forward commitments as of this snapshot (26 October 2026), not completed events, and should be re-checked against the live developer portals before you rely on them for a go-live date.