DHL Retires Legacy SOAP API for German Parcels

DHL retires legacy SOAP API for German parcels: what changed and when

DHL Group's Post & Parcel Germany division has pulled the plug on version 3 of its SOAP-based Geschäftskundenversand (Business Customer Shipping) API. DHL's own developer portal confirms that the legacy version 3 of the SOAP Business Customer Shipping API will no longer be supported as of May 31, 2026, after which no shipments can be created and no shipping labels can be generated via this interface. The production DNS switch to the new infrastructure took place shortly after, with the DNS switch scheduled to take place between 22-29 June, 2026 on the production environment (api-eu.dhl.com).

If you're still running the old SOAP integration, this isn't a warning shot. It's already live. A migration to the new REST API DHL Parcel DE Shipping V2 is required, with DHL recommending the switch to benefit from a faster, more stable, and secure connection using the OAuth 2.0 standard. This applies specifically to Post & Parcel Germany's business customer shipping interface, not DHL Express or DHL Freight, which run entirely separate APIs and separate deprecation timelines.

The quieter change nobody flagged: your Warenpost product code stopped working too

DHL's SOAP shutdown wasn't the only thing that broke on May 31. A second, less-publicized change landed on the same date and it's the one catching integrators off guard.

On January 1, 2025, DHL introduced the new product DHL Kleinpaket, replacing the previous product Warenpost. Until then, DHL's system had automatically converted the outdated product code for Warenpost into DHL Kleinpaket as a backend workaround. That silent conversion is now gone. For technical reasons, this workaround was deactivated as of May 31, 2026, and anyone still using the outdated product code for Warenpost needs to switch to DHL Kleinpaket, replacing "V62WP" with "V62KP" in their integration.

This is the kind of change that breaks things invisibly. Your code kept "working" for over a year because DHL was quietly fixing your mistake for you. Now it isn't. If your shipment-creation logic anywhere still hard-codes V62WP, you're not getting a converted label anymore, you're getting a rejected order. The physical product changed too: DHL Kleinpaket allows shipping goods up to 25 cm x 35.3 cm x 8 cm and up to 1,000 g, expanding the previous maximum height of 5 cm to 8 cm, so this isn't purely a cosmetic rename.

A tracking backend change worth watching too

Separately, DHL decommissioned a tracking backend that some integrations may still reference directly. Within Shipment Tracking – Unified API (UTAPI), the service post_de was decommissioned on 25 February 2026, and incoming shipment tracking requests are now routed to svb or parcel-de depending on the shipment, with both services providing information to ensure continued tracking visibility. The catch: the data retention policy for shipment tracking may differ depending on the underlying backend, meaning API consumers may occasionally receive a 404 error for shipments that were previously available. If your customer-facing tracking page or middleware assumes DHL tracking history is permanently retrievable, test against older shipment numbers now rather than waiting for a support ticket.

Migration checklist and dates

Why this keeps happening, and who actually has to fix it

This isn't DHL's first protocol shakeup in this window, and it won't be the last. The pattern repeats across European carriers as they push customers off SOAP and XML toward REST and OAuth 2.0, a shift documented more broadly in ShipperHQ's overview of 2026 carrier API changes. What determines whether this is a fire drill or a non-event for your team is entirely about who owns the DHL connection.

If your organization built and maintains its own DHL SOAP integration in-house, you had a hard deadline to rebuild against the REST spec and fix every hard-coded product string. If you route DHL traffic through a TMS with carrier connectivity built in, such as Cargoson, nShift, Shiptify, or FreightPOP, that migration work is typically absorbed by the vendor without you touching a line of code. Platforms like MercuryGate, Descartes, Transporeon, Sendcloud and Shippo sit somewhere in between depending on whether they built the DHL connector themselves or subcontracted it. Neither approach is universally superior, but pretending you don't know which camp you're in is how integrations fail quietly for months before anyone notices the failed shipment count creeping up.

Practical steps if you manage your own DHL connection

• Confirm your current API credentials are registered against DHL Parcel DE Shipping V2 in the developer portal, not the legacy GKV SOAP endpoint.
• Grep your shipment-creation codebase for any hard-coded "V62WP" string and replace it with "V62KP".
• Add monitoring specifically for 404 responses on tracking calls tied to shipments created before February 2026.
• Re-run label generation through DHL's sandbox before assuming production traffic is clean, especially for Kleinpaket and returns flows.
• If you use a third-party shipping module or ERP plugin, contact the provider directly to confirm they've shipped the REST migration rather than assuming it's automatic.

Check your logs for the last 30 days. If you're seeing failed label generation or unexpected 404s on German parcel shipments, this is almost certainly why.