These are the known limitations of the Kuehne+Nagel integration. They are inherent to the current design of the integration and to the capabilities of the Kuehne+Nagel API, and they apply to all subscribers at the time this documentation was written.

This integration was built for the Kuehne+Nagel LTL Plus shipment-tracking service, reached at https://api.ltlp.kuehne-nagel.com/api and administered through the LTL Plus portal at https://my.ltlp.kuehne-nagel.com.

Kuehne+Nagel does not publish a versioned public specification for this service, so the integration was built against its documented production endpoints. This documentation describes integration version 1.0.1 and was reviewed on 28 July 2026.

Not built for. Kuehne+Nagel operates several other API platforms that this integration does not support and cannot be pointed at:

If Kuehne+Nagel launches a separate product line or a materially different API version in the future, this integration will not automatically support it.

The integration reads shipment tracking information from Kuehne+Nagel and records it in iPaaS.com. It never writes to Kuehne+Nagel.

What this means for you: booking a shipment, changing one, or cancelling one is done in Kuehne+Nagel directly. Nothing you change on the iPaaS.com tracking record travels back to Kuehne+Nagel, so treat Kuehne+Nagel as the source of truth for shipment status and iPaaS.com as the place it is reported alongside the order.

Kuehne+Nagel does not notify iPaaS.com when a shipment changes, so the integration asks for updates on a schedule you set on the shipment/poll event. Tracking information is therefore as current as the last completed polling run rather than instantaneous.

What this means for you: choose a polling frequency that matches how quickly your team needs status. A shorter interval keeps status fresher at the cost of more calls to Kuehne+Nagel. Manual Sync is always available when you need one shipment brought up to date immediately, without waiting for the next scheduled run.

Kuehne+Nagel sometimes revises a shipment after the status date the record carries. A polling run that searches only since the previous run can miss such a revision, because the shipment's own dates place it outside the window.

What this means for you: set the optional filter value on the polling event to the number of days your shipments typically take to settle, and each run will search that far back beyond the previous run. The value must be a whole number of days — anything else causes the polling run to stop. If you are unsure what to use, start with a small number and widen it if you find revisions arriving late.

The integration does not offer an initialization or bulk-import mode, so connecting a subscription does not pull in shipments that already exist in Kuehne+Nagel. Polling begins from the point the subscription starts running.

What this means for you: if you need an existing backlog of shipments in iPaaS.com, load it deliberately using bulk sync using Postman, which lets you drive the transfers yourself at a pace you control. Day-to-day operation needs no such step.

Tracking is attached to an order, not stored on its own. The integration matches the shipment's Reference Number to an iPaaS.com Transaction Number and writes the tracking record against the Transaction it finds. It never creates the Transaction.

What this means for you: the order must reach iPaaS.com before its shipment does, through whichever integration owns your orders. If a shipment arrives first, its transfer stops with an error naming the Reference Number, and it succeeds on a later attempt once the order is present. The match is exact, so confirm that the reference your team enters in Kuehne+Nagel is the same value that becomes the iPaaS.com Transaction Number — including case and any leading zeros.

iPaaS.com validates the shipping method recorded on a tracking record against the Shipping Methods configured in your subscription. Kuehne+Nagel service names are not created in iPaaS.com automatically.

What this means for you: create the Shipping Methods you intend to record before enabling the collection. The integration ships with a single fixed starter value, which must either be created in iPaaS.com or repointed at one of your own — see the Placeholder Values section below. If you want the real carrier service recorded per shipment rather than one fixed value, create those Shipping Methods first and then change the mapping to resolve to them.

Where more than one iPaaS.com Transaction carries the same Transaction Number, the shipment attaches to the first match found.

What this means for you: keep Transaction Numbers unique in iPaaS.com. If duplicates are possible in your order flow, resolve them upstream, because the integration cannot tell which of two identically-numbered orders a shipment belongs to.

When a shipment transfers again, iPaaS.com replaces the tracking record rather than merging into it. Any field on the tracking record that this collection does not map is written as empty. In the mappings as shipped, the affected field is Cost, which the Kuehne+Nagel shipment data does not supply.

What this means for you: if you populate Cost on a tracking record by another route — by hand, or from another integration — the next Kuehne+Nagel transfer for that shipment clears it. To preserve a value that Kuehne+Nagel does not provide, add a mapping for that field using the DestinationValue function so each transfer writes back the value already on the record. Fields this collection does map are expected to be overwritten on every transfer; that is how status stays current.

Deletions are not propagated in either direction. A shipment removed in Kuehne+Nagel leaves its tracking record in place in iPaaS.com, and delete mappings are not included in the default templates.

What this means for you: remove the tracking record in iPaaS.com yourself if a shipment is cancelled and you do not want it reported against the order. This is uncommon in practice, because a cancelled shipment usually reaches a terminal status in Kuehne+Nagel that transfers normally.

The collection does not offer selectable collision-handling methods. Records are matched by the link iPaaS.com records after the first successful transfer, so a shipment that has transferred before updates its existing tracking record instead of creating a duplicate.

What this means for you: no configuration is needed for this to work correctly. Be aware only that if another integration in the same company also writes tracking records against the same Transactions, both can attach to it — decide which system owns shipment status before enabling both.

Kuehne+Nagel validates credentials when a request is actually made, so saving the subscription settings does not by itself confirm they are correct.

What this means for you: after entering your credentials, run a Manual Sync for a shipment you know exists rather than assuming a saved page means a working connection. If the credentials are wrong, that first transfer fails with a message showing what Kuehne+Nagel returned, and the fix is to re-check the values against those issued by the Kuehne+Nagel Helpdesk.

Kuehne+Nagel supplies the status date and the status time as separate values and does not publish a fixed format for the time. iPaaS.com stores it exactly as supplied without parsing it, validating it, or converting it to your subscription's time zone.

What this means for you: read the status time alongside its accompanying time code, and treat both as text to display rather than values to calculate with. Build reporting on the status date where you need to sort or filter by time.

The integration ships with one value that is an example rather than a working setting. It must be resolved before the collection is enabled.

This document covers 13 limitations of the Kuehne+Nagel integration. For detailed technical documentation of how each field is transferred, see the mapping collection descriptions in iPaaS.com and the Kuehne+Nagel to iPaaS.com Transaction Tracking Number Mapping Documentation.