PostNord Moves Order Integration From EDI To API

What Happened

PostNord is shutting down file-based EDI order submission across its Nordic markets and replacing it with its REST-based Booking API, and it's doing this country by country rather than in one coordinated cutover. According to nShift's migration notice, PostNord is moving from file-based order integrations to the new Booking API, and nShift Ship customers must switch to the API as PostNord will no longer support EDI shipments. If you maintain your own connection to PostNord, or run it through a TMS or shipping platform, this is already affecting you in Sweden and Denmark, and it's coming for Finland next.

PostNord's own Sweden developer portal and Denmark's dedicated migration campaign page both frame this the same way: file-based EDI is being phased out in favor of API calls that validate data in real time. This isn't a rumor or a future roadmap item. Deadlines have already passed in two countries, and a fee is about to kick in for anyone still sending files in Sweden.

The Deadlines That Already Passed, And The One That Hasn't

Here's where things actually stand, market by market:

If you still have Norwegian volumes running through PostNord, there's no forcing function yet. Treat that as a watch item, not a free pass.

Why PostNord Is Doing This

The stated rationale is consistent across every PostNord-published source: file-based EDI is slow to validate and expensive to support at scale. PostNord's own developer portal explains it plainly: an API acts as a digital bridge that allows different systems to communicate and share EDI data in a standardized way, and instead of transferring information via EDI files, an API can be used to verify, send, and receive the information in real time. The benefit framing on the Denmark campaign page is similarly direct: by the transition to APIs, you will achieve instant transfer of data without manual interference and thus less risk of errors, your customers will get tracking and notifications in real time, and you will be notified instantly if there are errors in the data you transfer. Fewer malformed files landing in PostNord's backend means fewer support tickets on their side. This is the same playbook you've seen from other Nordic and European parcel carriers retiring legacy file flows in favor of REST APIs. PostNord isn't an outlier here, it's following the same path as everyone else moving away from batch EDI.

What Actually Changes For Your Integration Team

If you connect to PostNord directly, your transport order payload structure moves from file/EDIFACT to REST/JSON calls against the Booking API, and your credentials move from file-transfer agreements to API keys and OAuth scopes issued per country entity. PostNord's own guides list separate onboarding mailboxes for each market: Denmark at [email protected], Finland at [email protected], Germany at [email protected], Norway at [email protected], and Sweden at [email protected]. Don't assume one contact gets you access across all four Nordic markets, it doesn't.

If you connect through a TMS or shipping platform like nShift, the carrier-facing engineering work is largely done for you, but the conversion isn't account-wide. nShift's Sweden documentation shows services are converted individually: nShift activates new services on your account to match your currently active PostNord services, organized into PostNord Parcel SE API, PostNord Groupage SE API, and PostNord Letters SE API as separate categories. That means your Parcel volume might already be on the API while your Groupage or Letters traffic is still generating file-based EDI, and racking up the SEK 1.00 per-package fee without anyone noticing.

A practical checklist before year-end:

• Identify which PostNord country entities you actually ship through (Sweden, Denmark, Finland, Norway all run on separate timelines and separate onboarding contacts).
• Check whether your Swedish volume is still flowing as file-based EDI. If so, you're exposed to the SEK 1.00 per-package charge starting 1 March 2026.
• Confirm your Danish connection status directly. The February 24, 2026 deadline for nShift Ship customers has already passed as of this writing, so if you're still on EDI in Denmark, you're past the line.
• Ask your platform vendor explicitly whether Finland and Norway conversions are scheduled for your account. "Ongoing" is not a date you can plan around.

Where This Fits In The Bigger Picture

PostNord is one carrier running one version of a pattern that's playing out across Nordic and European parcel networks: retire the file flow, force migration to API, charge a surcharge to speed up the laggards. This is exactly why most mid-to-large shippers don't try to track every carrier's EDI retirement schedule manually. Platforms like nShift, Sendcloud, ShipStation, EasyPost, AfterShip, ClickPost, and TMS systems such as Cargoson that maintain carrier connections natively exist precisely to absorb this kind of churn so you're not the one discovering a surcharge on your Swedish invoice three months after it started.

What To Do Before Year-End

1. Confirm which PostNord country contract you're on and whether the Swedish EDI surcharge applies to your account.
2. Get a straight answer from your TMS or connectivity vendor on which PostNord services (Parcel, Groupage, Letters) are already converted to API for your specific account, not just "PostNord is supported."
3. If you're self-integrated, request Booking API credentials from the relevant country mailbox now, rather than waiting for a forced deadline to catch you mid-peak-season.
4. Keep an eye on Norway. There's no published deadline yet, but given the pattern in Sweden, Denmark, and Finland, one is coming.

This isn't a one-off PostNord quirk. Expect the same sequence, file-flow deprecation notice, extension period, final deadline, fee for stragglers, from other Nordic and European carriers over the next two years. The ones who get caught off guard are usually the ones who assumed their carrier integration was a "set it up once" project.