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

This integration was built for ShipBob, the fulfillment and logistics platform. It calls the ShipBob Developer API at marketplaceapi.shipbob.com, version 2026-01. It was last tested end-to-end against the ShipBob sandbox on 2026-07-06.

This integration is not built for other fulfillment, warehouse-management, or third-party-logistics platforms, and it cannot be pointed at them. If ShipBob releases a separate product line or a materially different API version in the future, this integration will not automatically support it.

Locations, location groups, shipping methods, product inventory, product variant inventory, and order tracking are captured from ShipBob into iPaaS.com. The integration does not push changes to these records back to ShipBob. Orders flow the other way — created in ShipBob from iPaaS.com transactions — and are written once at creation; the integration does not re-sync or update an order after it is created.

What this means for you: For the captured record types, ShipBob is the source of truth and iPaaS.com reflects what ShipBob reports on each capture. Manage these records in ShipBob, not in iPaaS.com. For orders, make sure the transaction is complete and correct in iPaaS.com before it is sent, because later changes are not propagated to the ShipBob order.

The record types captured from ShipBob are refreshed by polling ShipBob on a schedule rather than by real-time change notifications.

What this means for you: A change made in ShipBob appears in iPaaS.com on the next scheduled poll rather than instantly. When you need a specific record captured immediately, use Manual Sync for that record.

An inventory record is only captured when its parent product (for product inventory) or parent product variant (for variant inventory) already exists in iPaaS.com. When the parent cannot be found, the transfer is stopped with an actionable error rather than creating an orphaned record.

What this means for you: Sync your products and product variants to iPaaS.com before enabling inventory capture. The match uses the parent's reference identifier by default — confirm your products are identified consistently, or change the match method (see the Placeholder Values section).

Inventory and location-group associations depend on the related ShipBob location or location group already being synced to iPaaS.com. When the related record has not yet been captured, the association is incomplete until it is.

What this means for you: Sync locations and location groups before relying on inventory or grouping data. After the related records are captured, re-syncing the dependent record completes the association.

Capturing a shipment's tracking depends on its related order already existing in iPaaS.com. When the order has not been synced, the tracking transfer cannot resolve its parent order.

What this means for you: Ensure the order is synced to iPaaS.com before its tracking is captured. Tracking is also only captured after ShipBob has assigned a tracking number — shipments without one are skipped until a later update or poll captures them.

The order flow creates orders in ShipBob. It does not update, cancel, or delete existing ShipBob orders. Captured record types are added and updated but not deleted from iPaaS.com by the integration.

What this means for you: Handle order changes, cancellations, and record deletions directly in ShipBob. The integration will not remove or reverse them on either side.

An order is sent to ShipBob with a single recipient shipping address — the transaction's primary shipping address. The integration does not split an order across multiple destination addresses.

What this means for you: If a transaction's intended recipient is not marked as the primary shipping address, adjust the mapping filter so the correct address is selected before enabling the order address collection. Orders that need to ship to multiple destinations must be split into separate transactions.

Creating an order requires a ShipBob channel identifier, which ShipBob does not display in its interface. The integration supplies it from the order mapping, and it is also used to resolve products when building the order.

What this means for you: Obtain your channel identifier through the ShipBob API (your implementation partner can help) and set it in the mappings before enabling the order flow. The shipped value is an example — see the Placeholder Values section.

The order's shipping method is matched against the shipping methods that exist in ShipBob. By default, a name that does not match an existing ShipBob shipping method stops the order so the method can be corrected before fulfillment.

What this means for you: Keep the shipping method names sent from iPaaS.com aligned with your ShipBob shipping methods, or choose the mapping formula variant that falls back to a default method. Note that when ShipBob auto-creates a shipping method from an order, it is unmapped and uses a default carrier, so review shipping method names before relying on auto-creation.

The integration does not provide a built-in bulk pull to load a full history of existing ShipBob records in one operation. Records are captured going forward by polling, and individual records can be captured on demand with Manual Sync.

What this means for you: To load a large set of existing records, subscribers or their MiSP can perform a bulk sync using Postman. For smaller needs, use Manual Sync per record.

The integration ships with example values in some mappings that each subscriber must replace before enabling the affected collection. Replace each of the following before go-live.

This document covers ten limitations of the ShipBob integration, plus the placeholder values to replace before go-live. For detailed, per-collection behavior, see the ShipBob mapping collection descriptions and mapping documentation.