Skip to main content

ShipStation Integration Known Limitations

Known limitations of the iPaaS.com ShipStation integration, including dependency, polling, deletion, and connection-test behavior, plus placeholder values to replace before go-live.

Introduction

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.

Platform Scope and Tested Versions

This integration was built for ShipStation and connects to the ShipStation API at the base address subscribers enter as the API Url during setup. It authenticates with HTTP Basic authentication built from a ShipStation API Key and API Secret.

The integration targets the ShipStation V1 API, which ShipStation publishes as production endpoints without a stable public version number. The integration was last tested end-to-end against ShipStation on 2026-06-29, as recorded in the QA Acceptance Test Checklist for this release.

Not built for: This integration is not built for the newer ShipStation API generation hosted on a separate ShipStation API address, and it is not built for any other product that ShipStation or its parent company may offer. If ShipStation introduces a separate product line or a materially different API in the future, this integration will not automatically support it. Subscribers should point this integration only at a ShipStation account reached through the V1 API.


1. No Automatic Dependency Transfers

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.


2. Inbound Shipments Use Polling and Manual Sync, Not Live Webhooks

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.


3. The Connection Test Does Not Validate Credentials

At the time this documentation was written, the subscription connection test reports success without actually checking the API Key and API Secret against ShipStation. 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 — for example, a Manual Sync of a single order or shipment — and confirm the record lands as expected. If a test transfer fails with an authentication-related error, re-check the API Key, API Secret, and API Url in the subscription settings. Subscribers or their MiSP should validate credentials this way in a staging environment before relying on them in production.


4. No Collision Handling

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 data, iPaaS.com is the source that writes into ShipStation; for shipment 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.


5. Records Are Not Deleted

The integration creates and updates records but does not delete them. An order removed in iPaaS.com is not deleted from 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. 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 to propagate should submit a feature request through their iPaaS.com partner channel.


6. Placeholder Values to Replace Before Go-Live

Two mappings on the Add/Update ShipStation Order FROM iPaaS.com collection ship with example values that demonstrate the intended shape of the data but are not meant for production. These are soft placeholders: the order still transfers with the example values in place, but the example data appears on the ShipStation order until it is replaced. Subscribers or their MiSP should review and replace both before go-live. These cross-reference the inline Placeholder value — replace during implementation callouts in the order mapping notes.

Advanced Options Formula (advancedOptions)

  • Collection: Add/Update ShipStation Order FROM iPaaS.com

  • Shipped default: A formula that sets a sample Saturday-delivery flag and a sample custom-field value ("My custom order value").

  • Why it's a placeholder: The shipped logic exists only to demonstrate the shape of the order's advanced options. The example flag and example custom-field text are not real subscriber data and will appear on the ShipStation order if left in place.

  • Suggested action: Replace the example logic and example values with your own advanced-options settings before enabling the transfer in production, or remove the mapping if you do not use ShipStation advanced options.

Amount Paid Default (amountPaid)

  • Collection: Add/Update ShipStation Order FROM iPaaS.com

  • Shipped default: The ShipStation order's amount paid is populated from the iPaaS.com transaction Subtotal.

  • Why it's a placeholder: Subtotal is a reasonable default but may not equal what the customer actually paid, for example before shipping or tax is applied. This value is informational within ShipStation and does not affect order creation.

  • Suggested action: Subscribers who track a true amount-paid value should change the source of this mapping to the field that represents the actual amount paid before go-live.


Closing

This article covers six 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.

Related Documents

Did this answer your question?