Summary
This article documents the four mapping collections that capture ShipBob inventory into iPaaS.com: Add ShipBob Product Inventory TO iPaaS.com, Update ShipBob Product Inventory TO iPaaS.com, Add ShipBob Product Variant Inventory TO iPaaS.com, and Update ShipBob Product Variant Inventory TO iPaaS.com. When a ShipBob inventory record is transferred, the integration reads the fulfillable and on-hand quantities ShipBob reports for a product or product variant at a specific fulfillment center location, resolves the iPaaS.com parent record and location the inventory belongs to, and creates or refreshes the matching iPaaS.com inventory record.
The business outcome is an iPaaS.com inventory picture that mirrors what ShipBob holds, broken down by location, so downstream processes can see current stock levels without leaving iPaaS.com. This is a capture flow only: it reads inventory from ShipBob into iPaaS.com and never writes inventory changes back to ShipBob. ShipBob owns inventory levels.
ID Format
Manual Sync ID. When a subscriber or their MiSP runs a Manual Sync for one of these collections, the identifier to enter is the ShipBob inventory identifier for the record to capture (for example, 13554). The product-inventory collections take a ShipBob product inventory identifier; the variant-inventory collections take a ShipBob product variant inventory identifier.
External ID saved after sync. After a successful transfer, iPaaS.com stores the ShipBob inventory identifier as the external ID on a dedicated external-ID record, following the identifier format {{id}} where {{id}} is the ShipBob inventory identifier. This link routes any subsequent transfer for the same ShipBob inventory record to the existing iPaaS.com inventory record rather than creating a duplicate, so repeat transfers update the record in place. Whether a given transfer results in an Add or an Update depends on whether the inventory record is already linked to an iPaaS.com record by this external ID.
Deleted Record Support
Not supported. These collections add and update inventory records. They do not remove inventory records from iPaaS.com, and they do not process inventory deletions from ShipBob. To retire an inventory record, subscribers or their MiSP manage it directly in iPaaS.com.
Custom Field Support
None. These collections map a fixed set of inventory fields into standard iPaaS.com Product Inventory and Product Variant Inventory fields and do not support custom fields.
Status and Trigger Events
All four collections are Enabled. This is a polling-only flow, kept in sync by scheduled polling and available on demand through Manual Sync. ShipBob does not push change notifications for this data, so inventory changes are picked up on the next scheduled poll rather than in real time. This flow is not driven by Inbound Data Flows webhooks.
The events that lead to a capture are:
A scheduled poll retrieves product inventory records that are new or changed since the previous poll, for the product-inventory collections.
A scheduled poll retrieves product variant inventory records that are new or changed since the previous poll, for the variant-inventory collections.
A subscriber or their MiSP runs a Manual Sync for a specific ShipBob inventory record.
Whether a captured record is routed to an Add or an Update collection is decided by whether the ShipBob inventory record is already linked to an iPaaS.com record by its external ID.
Duplicate or Conflicting Collections
The Add and Update collections are paired and work together rather than conflicting:
Product inventory. Add ShipBob Product Inventory TO iPaaS.com creates the inventory record and resolves its parent product link when the record is first captured. Update ShipBob Product Inventory TO iPaaS.com targets an inventory record that is already linked in iPaaS.com and refreshes its quantities.
Product variant inventory. Add ShipBob Product Variant Inventory TO iPaaS.com creates the record and resolves its parent product variant link. Update ShipBob Product Variant Inventory TO iPaaS.com targets an already-linked record and refreshes its quantities.
In both pairs, Add-versus-Update routing is decided by whether the ShipBob inventory record is already linked to an iPaaS.com record by an external ID. Review the Add and Update settings on both collections before enabling so that new inventory is created once and subsequent quantity changes update in place.
Supported Child Collections
None. Each of these collections is standalone: it captures a single inventory record with no dependent child collections.
System Caveats
Location must be synced first. Each inventory record is linked to the iPaaS.com location it is held at, resolved from the ShipBob location carried on the record. That location must already be synced to iPaaS.com through the Location TO iPaaS.com collection before inventory is captured. If the location has not been synced, the inventory row cannot resolve its location. This is a reference-data prerequisite for the flow.
Parent product or product variant must exist. The product-inventory collections link each inventory record to a parent product in iPaaS.com; the variant-inventory collections link each record to a parent product variant. The parent is resolved from a match value carried on the ShipBob inventory record. If the parent does not yet exist in iPaaS.com, the transfer is stopped by a by-design guard rather than creating an orphaned inventory record. Sync the parent products or product variants to iPaaS.com first.
Inventory is read-only. ShipBob owns inventory levels. These collections read inventory from ShipBob into iPaaS.com; they do not write inventory back to ShipBob.
Rate limits. ShipBob applies a rate limit of 150 requests per minute. When ShipBob rate-limits a request, the transfer is rescheduled automatically to resume after the limit window resets, and no subscriber action is required.
Integration Flow
A scheduled poll runs, or a subscriber or their MiSP runs a Manual Sync for a specific ShipBob inventory record.
The integration reads the inventory record from ShipBob, including the fulfillable and on-hand quantities and the ShipBob location.
The integration resolves the iPaaS.com location the inventory is held at from the ShipBob location. If no matching location exists in iPaaS.com, the location cannot be resolved and the inventory row fails until the location is synced.
For the Add collections, the integration resolves the parent product or product variant from the match value carried on the record. If the parent does not resolve to an existing iPaaS.com record, the transfer is stopped by the parent-resolution guard so the parent can be synced first. The Update collections target an inventory record that is already linked in iPaaS.com and do not re-resolve the parent.
The integration creates or refreshes the iPaaS.com inventory record, carrying the fulfillable and on-hand quantities against the resolved parent and location. Whether the result is an Add or an Update depends on whether the inventory record is already linked to an iPaaS.com record by its external ID.
Mappings
Add / Update ShipBob Product Inventory TO iPaaS.com
iPaaS.com data type: Product Inventory
These two collections capture ShipBob product inventory. Their field mappings are identical except that the Add collection also resolves and sets the parent product (ParentId), which the Update collection omits because it targets an inventory record that is already linked in iPaaS.com. Neither collection has a mapping filter, so every dispatched inventory record is processed.
Destination Field | Source | Description |
ParentId | Resolved iPaaS.com product from the record's match value | Add collection only. Links the inventory record to its parent product in iPaaS.com. Required: inventory in iPaaS.com is held under a product, so the parent product must be resolved before the record can be created. The match value defaults to the reference identifier, with SKU, barcode, GTIN, and UPC provided as commented alternatives. Placeholder value — replace during implementation: the shipped formula defaults to matching by reference identifier through the line var match = ReferenceId.ToString();; select the match method that matches how your products are identified in iPaaS.com before enabling this collection. If the match value does not resolve to an existing iPaaS.com product, the transfer is stopped with the by-design guard message Can't create product inventory because sku ... does not exist in iPaaS rather than creating an orphaned record. |
LocationId | Resolved iPaaS.com location from the ShipBob location | Links the inventory record to the iPaaS.com location it is held at, resolved from the ShipBob location carried on the record. Required: the ShipBob location must already be synced to iPaaS.com through the Location TO iPaaS.com collection. If no matching location is found, no location is resolved and the inventory record cannot be linked to a location. |
QtyAvailable | ShipBob fulfillable quantity | Sets the fulfillable quantity on the iPaaS.com Product Inventory record from the quantity ShipBob reports as available to fulfill at the location. Required: it is the core inventory figure this flow captures. |
QtyOnHand | ShipBob on-hand quantity | Sets the on-hand quantity on the iPaaS.com Product Inventory record from the quantity ShipBob reports as physically on hand at the location. Required: it captures the on-hand stock level alongside the fulfillable quantity. |
Add / Update ShipBob Product Variant Inventory TO iPaaS.com
iPaaS.com data type: Product Variant Inventory
These two collections capture ShipBob product variant inventory. Their field mappings are identical except that the Add collection also resolves and sets the parent product variant (ParentId), which the Update collection omits because it targets an inventory record that is already linked in iPaaS.com. Neither collection has a mapping filter, so every dispatched inventory record is processed.
Destination Field | Source | Description |
ParentId | Resolved iPaaS.com product variant from the record's match value | Add collection only. Links the inventory record to its parent product variant in iPaaS.com. Required: inventory in iPaaS.com is held under a product variant, so the parent must be resolved before the record can be created. The match value defaults to the variant's reference identifier, with SKU, barcode, GTIN, and UPC provided as commented alternatives. Placeholder value — replace during implementation: the shipped formula ships a //Adjust to your match method template that defaults to matching by reference identifier through the line var match = ReferenceId.ToString();; replace it with the match method that fits your catalog before enabling this collection. If the match value does not resolve to an existing iPaaS.com product variant, the row is rejected with the by-design guard message Can't create variant inventory because sku ... does not exist in iPaaS rather than creating an orphaned record. |
LocationId | Resolved iPaaS.com location from the ShipBob location | Links the inventory record to the iPaaS.com location it is held at, resolved from the ShipBob location carried on the record. Required: the ShipBob location must already be synced to iPaaS.com through the Location TO iPaaS.com collection. If no matching location is found, no location is resolved and the inventory row fails. |
QtyAvailable | ShipBob fulfillable quantity | Carries the fulfillable quantity ShipBob reports for the variant into the iPaaS.com inventory record. Required for a meaningful inventory sync. |
QtyOnHand | ShipBob on-hand quantity | Carries the on-hand quantity ShipBob reports for the variant into the iPaaS.com inventory record. Required for a meaningful inventory sync. |
Error Handling
Errors from this flow appear in the iPaaS.com Dashboard under Integration Monitoring and Error Logs. The most common message subscribers or their MiSP will see is the parent-resolution guard, which stops a transfer when the inventory record's match value does not resolve to an existing iPaaS.com product or product variant. This is an intended guard, not a defect: it prevents an orphaned inventory record and surfaces the mismatch so the parent can be synced first or the match method adjusted. For the specific messages this integration can produce, their causes, and how subscribers or their MiSP resolve each one, see the ShipBob Error Messages article.
Testing and Validation
Confirm the ShipBob location the inventory is held at is already synced to iPaaS.com through the Location TO iPaaS.com collection. If it is not, sync the location first so the inventory record can resolve its location.
Confirm the parent product or product variant is already synced to iPaaS.com, and confirm the ParentId match method matches how your catalog identifies products and variants.
In ShipBob, identify an inventory record to capture, and note its inventory identifier.
On the iPaaS.com Manual Sync page, select the relevant collection (product inventory or product variant inventory) and enter the ShipBob inventory identifier.
Run the Manual Sync and confirm the transfer completes without error.
Open the parent product or product variant in iPaaS.com and confirm the inventory record carries the expected fulfillable and on-hand quantities at the correct location.
To confirm the guard behavior, attempt a Manual Sync for an inventory record whose parent has not been synced and confirm the transfer is stopped with the parent-resolution message rather than creating an orphaned record.
Additional Notes and Out of Scope
No write-back to ShipBob. These collections capture inventory from ShipBob into iPaaS.com. They do not push inventory changes back to ShipBob. ShipBob owns inventory levels.
Add versus Update split. New inventory records are created by the Add collections, which also resolve the parent product or product variant link. The Update collections refresh the quantities on records that are already linked in iPaaS.com and do not re-resolve the parent. Routing between them is automatic, based on whether the record is already linked by external ID.
Location prerequisite. Capturing inventory depends on the ShipBob location already being synced to iPaaS.com. Subscribers or their MiSP should ensure locations are synced first through the Location TO iPaaS.com collection and validate this behavior in a staging environment before relying on it in production.
Parent prerequisite. Capturing inventory depends on the parent product or product variant already existing in iPaaS.com. Subscribers or their MiSP should sync products and product variants first so each inventory record can be linked to its parent.