Migrating DPD From EDIFACT IFTMIN To Its REST API

DPD's Shivah Webservice has run two parallel stacks for a while now: the legacy SOAP/XML interface most European shippers built against years ago, and a newer JSON-based REST API. If your integration still sends IFTMIN EDIFACT messages into a translator that maps onto DPD's older infrastructure, or if you've been on SOAP and are wondering whether it's worth the rebuild, this walkthrough covers the actual mechanics of a DPD API integration migration: authentication, the shipment endpoint, status retrieval, and the one failure mode that catches almost everyone the first time.

Why move off IFTMIN for DPD specifically

DPD itself frames REST as the direction to build in going forward. Its REST interface is described as ideal for new integrations, built for high performance, fast response times, and easy implementation, suited to real-time processes and agile system landscapes. SOAP hasn't gone away DPD still offers stable SOAP interfaces for existing XML-based architectures to ensure reliable integration into complex enterprise systems but the direction of travel is clear. DPD's own guidance to SOAP users is direct: evaluate a switch to the REST API during the migration to benefit from higher efficiency and lower long-term complexity.

If your connection to DPD currently runs through an EDIFACT IFTMIN feed via FTP, you're one step further back than SOAP users, translating transport instruction segments into whatever your EDI translator expects DPD to understand. That's a pattern you'll hit again with other CEP carriers, not just DPD, so the mapping work here is reusable.

Before you start: what you need in place

Don't start mapping fields until you have these four things confirmed, or you'll redo work halfway through.

• A DPD Shipper account and customer number, plus separate credentials for the stage (test) and live environments – tokens from one won't authenticate against the other.
• Sign-off that your integration will go through DPD's validation process. Each development using the DPD Shipper Webservice must be validated and approved by DPD before production access is granted, with the implemented services and products tested first. Budget calendar time for this, it isn't instant.
• A field-level export of your current IFTMIN structure: which segments you populate for shipper, consignee, carrier, pickup/delivery locations and references. The NAD-LOC-MOA segment group in IFTMIN identifies a party, related references, locations, contacts, required documents, and charges to be paid by that party, and that's the group you'll be translating into JSON objects.
• A decision on who owns the mapping work. Large shippers with in-house EDI teams typically do this directly against DPD's REST documentation. Mid-size shippers without a dedicated integration team more often route this through a TMS with carrier connectivity built in, such as Cargoson, nShift or Shiptify, rather than building and maintaining the DPD-specific logic themselves.

Step-by-step: migrating the connection

1. Authenticate and cache a token via the login service. DPD's REST login endpoint issues a token you'll reuse across all subsequent calls. The token is valid for exactly 24 hours after authentication, so one call to the login service per 24 hours is sufficient to access all other DPD Shipper Webservices. Call it at POST https://wsshipper.dpd.nl/rest/services/LoginService/V2_1/getAuth for live, or the equivalent stage URL for testing. Store the returned token and its expiry in your integration middleware's cache layer, not in a per-request variable. You can cache the token and re-use it for any call within the 24 hour limit, and it's not allowed to refresh your token for each request.
2. Map your IFTMIN payload onto the shipment service request. The shipment service is used to generate parcel labels, and a request will only succeed with an active authentication token generated in the login service. Where your IFTMIN message used NAD segments for shipper, consignee and carrier, and LOC for pickup/delivery, your JSON payload needs equivalent sender, receiver and parcel objects. A simplified skeleton looks roughly like this:{
   "sender": { "name1": "...", "street": "...", "country": "DE", "zipCode": "...", "city": "..." },
   "receiver": { "name1": "...", "street": "...", "country": "FR", "zipCode": "...", "city": "..." },
   "product": "CL",
   "parcels": [ { "weight": 5.2 } ],
   "customerReferenceNumber1": "PO-2026-00341"
   }DPD's own documentation starts from a Basic Request, described as the minimum request needed to create a successful request and a parcel label, so treat the fields above as a floor, not the full schema, before you build in your product codes and pallet-specific weight/dimension fields.
3. Submit against stage and confirm a valid label comes back. Test data submitted here doesn't create real shipments. Shipment data submitted on the stage environment's storeOrders endpoint is treated under GDPR and security regulations, and DPD stores requests for a reasonable period to perform metrics and analysis, so use realistic but non-production references rather than live customer data. You know it worked when you get back a valid parcel/tracking number and a renderable label. If you're testing the paperless flow, the e-label comes back as a PNG image containing a QR code, which a DPD parcel point scans in place of a printed label.
4. Replace your IFTSTA-style status polling with DPD's parcel lifecycle check or callback. DPD gives you two options: request parcel statuses on demand, or register a call-back where DPD's system pushes data to your endpoint whenever a status changes. For any meaningful shipment volume, callback beats polling for the obvious reason: you're not burning API calls checking parcels that haven't moved. If you do poll, respect the batch limit: you can have up to 30 parcels checked per request, and if more need checking, you make multiple requests.

The failure mode: token throttling that silently blacks out shipments

This is the one that catches teams who treat the REST migration as "same logic, new URL." DPD enforces a hard daily cap on the login service itself: an authentication token must be generated via the login service and used in all following API calls, is valid for one business day CET/CEST and must be cached, and calling the login service more than 10 times a day is prohibited. If your old SOAP or IFTMIN integration pattern re-authenticated per batch job or per warehouse shift, porting that habit straight into REST will burn through the daily login allowance by mid-morning.

There's a second, quieter version of the same problem on the shipment side. All shipment service API calls must be done sequentially, with only a single request permitted at a time, and if you're using more than one IP address such as a load-balancing cluster, you need to ensure no calls are sent simultaneously, or you risk an application ban. A load-balanced order management system that fires shipment requests from multiple nodes in parallel is exactly the setup that trips this.

The fix is architectural, not a config tweak. Put token issuance behind a single lock or singleton in your integration layer so only one process ever calls the login service, and cache the result centrally for every worker to read. Serialize shipment calls through a queue rather than letting parallel workers hit the endpoint at once. And alert on token age before expiry, not after a batch of shipments fails, because a failed 6am pick-pack run because of an expired token is a much worse Monday than a proactive refresh at 11pm the night before.

This exact category of operational risk, token lifecycle management and rate-limit handling done wrong in custom code, is what pushes some shippers toward multi-carrier platforms that manage authentication and failover natively rather than in a bespoke integration layer.

Comparing your options for who owns this logic

Rollback and parallel-run strategy

Don't decommission IFTMIN the day your first REST shipment prints correctly. Run both paths in parallel through one full peak cycle, comparing label output, tracking numbers and status events between the two before you cut over fully. Keep the IFTMIN/FTP path warm and reachable for at least 30 days after cutover in case you need to fall back.

Before calling the migration done, check off: tokens cached for the full 24-hour window with alerting before expiry, storeOrders field mapping validated against real shipment types (parcel and pallet), a callback endpoint live and receiving status pushes, stage-tested labels matching production format including e-label QR rendering, and a fallback IFTMIN path kept operational for one full cycle after go-live.