This article describes the known limitations of the iPaaS.com ShipStation integration at the time this documentation was written. These limitations are inherent to the integration's current design and to the capabilities of the ShipStation API, and they apply to all subscribers. Each limitation is described first in plain technical terms and then in a short What this means for you explanation with the recommended action where one exists.

This integration was built for ShipStation and connects to two generations of the ShipStation API from the same subscription. Shipments and shipping methods are read from ShipStation through the ShipStation V1 API at the address subscribers enter as the API Url, authenticated with HTTP Basic authentication built from a ShipStation API Key and API Secret. Orders are sent to ShipStation as shipments through the ShipStation V2 API at the address subscribers enter as the V2 API Base URL, authenticated with a V2 API Access Key.

ShipStation publishes both API generations as production endpoints without a stable public version number. The integration was last tested end-to-end against ShipStation on 2026-09-28, as recorded in the QA Acceptance Test Checklist for this release.

Not built for: This integration is not built for any other product that ShipStation or its parent company may offer, and it does not use the ShipStation V2 API for anything other than creating and updating shipments. If ShipStation introduces a separate product line or a materially different API in the future, this integration will not automatically support it. At the time this documentation was written, ShipStation makes both API generations available only on plans that include API access, and its separate developer product (ShipStation API) offers the V2 shipment endpoints without the V1 API this integration also needs, so subscribers should confirm they hold a ShipStation platform plan with API access before installing.

When an iPaaS.com order is transferred, the integration creates a ShipStation shipment for it and asks ShipStation to create the matching sales order so the order is visible in ShipStation. It does not purchase a shipping label, and it does not set the carrier, the shipping service, or the package dimensions. The shipment arrives in ShipStation with a Pending status. Because the order is written as a shipment, it carries only the shipment fields the shipped mappings populate; ShipStation options such as advanced options and customs contents are not mapped in the shipped template.

What this means for you: Treat iPaaS.com as the source of the order and its line items, and complete the shipping decisions in ShipStation. After a shipment arrives, select the carrier and service, confirm the package details, and purchase the label in ShipStation.

The shipment address collection does expose additional shipment fields that the shipped mappings deliberately leave unmapped, including the carrier, the shipping service, the shipment status, package dimensions, insured value, and label reference messages. Mapping them is possible, but it is not recommended unless you or your MiSP have confirmed the result in a staging environment: a shipment that arrives with its carrier, service, and status already set can be picked up by ShipStation automation and batch workflows, and labels and carrier charges can then be created for shipments nobody has reviewed. Subscribers who need labels purchased automatically, or ShipStation order-level options set from iPaaS.com data, should submit a feature request through their iPaaS.com partner channel rather than enabling these fields ad hoc.

With Enable Multi Address Shipment turned on, the integration splits an order into one shipment per destination address using the destination each line item names in the ShipToAddressExternalId custom field. The integration resolves that value to an address on the order; it does not infer a destination from the line item itself. A line item whose value is empty ships with the order's primary shipping address; a line item whose value does not resolve to an address on the order is not shipped and the transfer reports it, while the order's other destinations are still sent. Line items that share a SKU but name different destinations are split by destination, so the same SKU can appear on more than one shipment.

What this means for you: Turn the setting on when your order source can name each line item's destination, using the same identifier it registers on the order's address in iPaaS.com. Line items without a destination ship with the order's primary shipping address, so single-address orders need no value; only a value that matches no address on the order fails and is reported. If your order source cannot supply destinations, leave the setting off; every order then ships as a single shipment to its primary shipping address and any destination values are ignored. Subscribers or their MiSP should confirm a multi-address order splits as expected in a staging environment before relying on it in production.

ShipStation requires a package weight on every shipment, and an order-placement system rarely knows the packed weight in advance. The integration reads the weight from the Package Weight custom field on the order's address, in the unit named by its Package Weight Unit custom field (ounces when that is empty), and sends 0 when the weight is empty or not present. ShipStation then recalculates the package weight shortly after it creates the shipment: when the order's line items carry a weight, the package weight becomes their total weight (each item's weight multiplied by its quantity); otherwise the weight sent is kept. ShipStation shows the package weight in ounces either way. One package per shipment is sent, and the shipped mappings do not transfer package dimensions or an insured value.

What this means for you: Expect to enter the weight (and dimensions) per package in ShipStation before purchasing a label, unless your order source can supply a weight. Subscribers whose order source knows the packed weight can create the Package Weight and Package Weight Unit custom fields as described in the Installation Instructions so the shipment arrives pre-filled; when the line items already carry weights, ShipStation's total of those weights is used instead; subscribers who also know the package dimensions can map them on the shipment address collection with their MiSP.

The inbound shipment flow brings ShipStation shipments into iPaaS.com as tracking records attached to the originating order. At the time this documentation was written, ShipStation's shipment list returns only shipments for which a label has been generated in ShipStation, so a Pending shipment the integration created is not visible to the inbound flow, and no tracking record exists on the iPaaS.com order, until the label is purchased. Once it is, each labeled shipment attaches to its originating order (one tracking record per shipment, so an order split across several destinations receives one tracking record per destination). Shipments for orders that were not created by the integration attach only if the order already exists in iPaaS.com and is identified by its ShipStation order id.

What this means for you: Expect the tracking number on an iPaaS.com order to appear after the label is purchased in ShipStation, not when the shipment is created. Tracking records carry the tracking number, carrier, service, and cost but not the line items each shipment contained; subscribers who need per-line shipment detail should submit a feature request through their iPaaS.com partner channel.

Shipments are created with ShipStation's address validation turned off, so ShipStation does not reject or correct an address. ShipStation nevertheless stores the ship-to address in its own standardized form, for example with the street and city in upper case and a nine-digit ZIP code where one is known.

What this means for you: The address shown on the shipment in ShipStation may differ cosmetically from the address on the iPaaS.com order. This does not change where the package ships. Subscribers who want ShipStation to validate addresses can change the validation setting on the shipment address mappings with their MiSP.

When a record references another record, the integration does not automatically create the referenced record if it does not already exist. The integration transfers each record on its own and does not perform a dependency transfer to fill in a missing parent or related record.

The clearest example is inbound shipment data. Each shipment that comes in from ShipStation is linked to the iPaaS.com order it belongs to. If that parent order has not already been synced into iPaaS.com, the shipment cannot be attached and a linked tracking record is not produced.

What this means for you: Make sure the records a transfer depends on are already present in iPaaS.com before the dependent record arrives. In particular, ensure orders are synced into iPaaS.com ahead of their shipments so each shipment's tracking detail can be linked to the correct order. If a shipment comes in before its order exists, sync the order and then re-run the shipment transfer.

Shipment data is brought into iPaaS.com by polling ShipStation for new and updated shipments on the integration's schedule, and by Manual Sync on demand. The integration does not register live shipment webhooks with ShipStation, so it does not receive an instant push the moment a shipment is created or updated in ShipStation.

What this means for you: New and updated shipments are detected on the polling schedule rather than instantly. You do not need to configure any shipment webhook in ShipStation for the integration to work, and you should not expect one to be required. To bring a specific shipment in immediately, run a Manual Sync for that shipment rather than waiting for the next poll.

Note: This limitation applies only to the inbound direction (ShipStation to iPaaS.com). Outbound order transfers from iPaaS.com to ShipStation are driven by the iPaaS.com order create and update triggers and by Manual Sync.

At the time this documentation was written, the subscription connection test reports success without actually checking any of the ShipStation credentials. A connection test can therefore pass even when the entered credentials are incorrect.

What this means for you: Do not rely on the connection test alone to confirm that your ShipStation credentials are valid. After entering or changing credentials, verify them by running a test transfer: a Manual Sync of a single shipment or the shipping method initialization confirms the V1 API Key and API Secret, and sending a single order confirms the V2 API Access Key. If a test transfer fails with an authentication-related error, re-check the corresponding key and base URL in the subscription settings. Subscribers or their MiSP should validate credentials this way in a staging environment before relying on them in production.

The integration does not implement collision handling. When the same record is changed in both ShipStation and iPaaS.com between transfers, the integration does not detect or reconcile the competing changes; the most recent transfer in a given direction writes its values without merging against an intervening change made on the other side.

What this means for you: Treat one system as the source of truth for each field rather than editing the same record in both places at once. For order and shipment data sent from iPaaS.com, iPaaS.com is the source that writes into ShipStation; for shipment tracking and shipping-method data, ShipStation is the source that writes into iPaaS.com. Subscribers whose workflow requires automatic reconciliation of simultaneous edits should submit a feature request through their iPaaS.com partner channel describing the specific reconciliation behavior they need; input like this informs future enhancement releases.

The integration creates and updates records but does not delete them. An order removed in iPaaS.com does not cancel or delete the shipment it created in ShipStation, and a shipment or shipping method removed in ShipStation is not deleted from iPaaS.com. Line items and addresses are likewise never removed as a standalone operation; they are written only as part of their parent order's create-or-update.

What this means for you: Deletions must be handled manually in each system. If you remove a record on one side and need it gone on the other, remove it there as well, and cancel any shipment in ShipStation that should no longer ship. This is a deliberate scope decision for the current release: the integration keeps data flowing in without removing records that a subscriber may still need. Subscribers who need automatic deletion or shipment cancellation to propagate should submit a feature request through their iPaaS.com partner channel.

The Ship From Location, store, currency, and package and line item weight units are not fixed in the shipped mappings. They are read from custom fields that the order source populates on each order, as described in the Installation Instructions, so they carry no example values to replace. One shipped mapping on the Add/Update ShipStation Shipment Address FROM iPaaS.com collection still uses a general-purpose default that subscribers or their MiSP should review before go-live. It cross-references the inline Placeholder value — replace during implementation callout in the shipment address mapping notes.

This article covers eleven known limitations of the iPaaS.com ShipStation integration as of the date this documentation was written. For detailed, per-collection technical documentation — including each collection's data requirements, out-of-scope items, and field-level mapping notes — refer to the iPaaS.com to ShipStation Order Mapping Documentation, the ShipStation to iPaaS.com Shipment Mapping Documentation, and the ShipStation to iPaaS.com Shipping Method Mapping Documentation.