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

The integration does not perform a bulk historical import when it is first connected. Existing records are not back-filled automatically on connection.

What this means for you: Populate historical data using Manual Sync for the records you need, and rely on the ongoing order polling and the outbound triggers you enable for new activity. There is no one-click "import everything" step.

Linnworks does not send order events to iPaaS.com, so the integration checks Linnworks for new and updated Open Orders on a recurring polling schedule rather than receiving instant notifications.

What this means for you: New and changed orders appear in iPaaS.com shortly after each poll rather than instantly. You can narrow polling to specific Linnworks locations with the Poll Orders By Locations subscription setting. Manual Sync is always available if you need a specific order transferred immediately.

When an order is captured from Linnworks, each line item's SKU must already exist as a Product in iPaaS.com. An order whose items are not found in iPaaS.com is not transferred, and an individual line whose SKU is missing is skipped.

What this means for you: Transfer your products to iPaaS.com before enabling order synchronization, so every order's items can be matched. Orders that reference unknown SKUs will not transfer until the matching products are present.

Inventory stock levels are written to Linnworks only when the iPaaS.com location maps to an existing Linnworks stock location by name. Records for a location with no Linnworks match are skipped.

What this means for you: Ensure your Linnworks stock locations exist and their names correspond to the locations used in iPaaS.com before enabling inventory synchronization, so stock levels are never written to an unknown location.

Order capture is based on the Linnworks Open Orders view. Orders that have moved out of Open Orders in Linnworks are outside the scope of the automatic poll.

What this means for you: Rely on the integration for orders while they are in the Open Orders stage. If you need an order that has already left that stage, use Manual Sync with its order identifier.

When the integration updates a record, it builds the update from the values you have mapped and sends that to the destination system. It does not first read the current destination record and merge your changes into it.

What this means for you: For any field you map, the source system is the source of truth — its value overwrites the destination value on each transfer. Fields you leave unmapped are not guaranteed to be preserved: because the update is not merged with the existing record, an unmapped field may be written with an empty or default value depending on how the destination system applies the update. Map every field whose value you need to keep maintained, and validate update behavior in a staging environment before relying on it in production. For fields you want to protect from being overwritten, an iPaaS.com DestinationValue mapping can carry the existing destination value forward.

Some shipped mappings use example values that each subscriber should confirm or replace before going live.

This document covers six known limitations plus one placeholder value to confirm before go-live. For detailed, per-collection behavior, see the individual mapping collection descriptions in iPaaS.com.