PostNL Moves Letterbox Parcels to Parcel Network API

PostNL moves letterbox parcels+ to its parcel network on 12 July 2026

PostNL's own developer changelog confirms it directly: effective 12 July 2026, letterbox parcels+ (24 hours) that are pre-announced with product codes 2928 and 2929 transition from the mail network to the parcel network, and from this date onward these parcels are handled by the parcel delivery network rather than the mail delivery network. If you ship Dutch letterbox parcels, this is not a cosmetic update. It changes which physical network handles the shipment, and that has knock-on effects for labels and scan data.

The immediate technical consequence: the label lay-out for this product changes, and as of 12 July the v2 APIs (Shipping v2 and Labelling v2) automatically generate and return a new label format for letterbox parcels pre-announced using productcode 2928 and 2929, though the output stays in landscape orientation. PostNL also added a new tracking signal alongside the change. The scan observation indicates that a shipment can't be delivered in the letterbox, for example when the shipment's dimensions are too large to fit, and it carries the Dutch description "Zending kan niet in de brievenbus", with the English label reading "Shipment can't be delivered in letterbox."

Who has to act, and who doesn't

This is the part worth reading twice if you run a PostNL integration. PostNL splits the required action by channel, not by product. Pre-announcement via API requires no action, since the API automatically generates the new label format for pre-announcements using productcode 2928 and 2929, letterboxparcel+. Legacy sFTP is a different story: customers currently pre-announcing through the legacy sFTP channel who wish to use the letterboxparcel+ standard (48 hours) will need to migrate to the API altogether, because that variant is no longer possible over sFTP at all.

That's the real lesson here. Shippers still on file-based sFTP flows sometimes treat that channel as the "stable" one precisely because it hasn't required maintenance in years. This change flips that assumption. The carrier can silently roll out a new label format under an API version number, and your integration just picks it up. A legacy sFTP connection, by contrast, needs someone to notice the changelog entry, update field mappings, and in some cases migrate the connection type entirely. If your team is on sFTP, budget time now, not after a shipment gets rejected at the sorting center.

For anyone keeping the scan feed, PostNL is explicit that the new observation should be built into your operational logic rather than ignored: store the scan observation and corresponding description in the appropriate harmonisation table, and make sure the applications that convert scan observations into business information recognise these scans and provide the correct information.

Part of a wider 2026 cleanup, not a one-off

The July letterbox change sits inside a run of PostNL platform changes this year. A simplification of the international product portfolio phased out a lot of contract-specific product codes from February 25th 2026, with the new product codes offering the exact same service, label and rates. Separately, PostNL tightened its US shipping rules: shipping to the United States and several US overseas territories is available again, but for shipments to the US and Puerto Rico a customs declaration and import duties are required for all shipments regardless of value, requiring a signed contract addendum authorizing PostNL to prepay duties, with stricter validation requiring a 10-digit HS code. And on the barcode side, PostNL is pushing customers off the RI format: the new barcode can be used with immediate effect, and it's recommended to change configuration as soon as possible as countries may decide not to process packets with RI barcodes anymore in 2026.

Why this matters beyond PostNL

DHL is running a parallel modernization in the same window, which makes mid-2026 a genuinely busy period for anyone maintaining direct carrier connections. On the DHL Group API Developer Portal, the legacy Returns API is being retired: if you are using a software solution for dispatching shipments, such as JTL, Gambio, Dreamrobot, etc., you need to contact the manufacturer immediately to switch to a new version in time before the shutdown date at the end of May 2026. DHL confirms the old interface stops working entirely after that: the legacy version of the Returns API under cig.dhl.de will no longer be supported as of May 31, 2026, and after this date no returns can be created and no return labels can be generated via this interface.

There's an infrastructure layer too. DHL's test and integration sandbox DNS switch will be completed by June 8, 2026, and the production environment DNS switch is scheduled between 22-29 June, 2026. If your firewall rules or IP allowlists are pinned to specific DHL endpoints, that's a separate ticket from anything product-related.

Put the two carriers side by side and the pattern is obvious: shippers running direct connections to PostNL, DHL, DPD, GLS and others are effectively tracking four or five independent changelogs at once, each with its own cadence, terminology and lead time. Missing one because it appeared as a two-paragraph note in a developer portal is exactly how a Tuesday morning label failure happens.

What to do before your next release cycle

• Identify which PostNL channel each of your integrations actually uses. Only Legacy sFTP customers need manual work for the 12 July letterbox change; API users get the new label format automatically.
• If a third-party dispatch tool handles PostNL or DHL for you, confirm compatibility with the vendor directly rather than assuming it's covered.
• Re-check HS code fields and customs data for any US-bound PostNL shipments given the new Puerto Rico and US import rules.
• Wire the new "can't be delivered in letterbox" scan code into exception handling, not just into a log table.
• If you're on DHL's legacy Returns API, move before 31 May 2026 and revalidate IP allowlists ahead of the June DNS changeover.

Shippers running many carrier connections at once, PostNL, DHL, DPD, GLS and bpost in parallel, increasingly hand this problem to a connectivity layer instead of tracking every changelog by hand, whether that's built in-house, delegated to a system integrator, or run through a platform like nShift, Sendcloud, ClickPost, Cargoson or FreightPOP that absorbs carrier-side format and endpoint changes on your behalf.

Bottom line

The 12 July PostNL change is small on its own. What it demonstrates is bigger: whether a carrier change is silent or breaking depends on which channel you're using, not on whether you're "integrated." API users got a free upgrade. Legacy sFTP users got a to-do item. That distinction, repeated across every carrier changelog you're not currently reading, is the actual maintenance cost of running your own carrier connectivity.