Summary
This documentation describes how iPaaS.com writes standalone product inventory — warehouse-scoped stock for a product — into Shopware. The family covers two collections that are triggered on their own when an iPaaS.com inventory record changes for a linked product: an Add collection that writes the initial inventory record and an Update collection that maintains it. These are the standalone inventory transfers; the same inventory data can alternatively be written as part of the full product transfer through the child inventory collection covered in the Shopware Product From iPaaS.com Mapping Documentation.
Inventory can be written on either of two paths. On the warehouse path the stock is written to a Shopware warehouse (product-warehouse) record, which requires the premium Shopware warehouse feature (Advanced Stock Management / multi-warehouse). On the non-warehouse path the warehouse write is bypassed and stock is applied directly to the parent product, for subscribers who do not use Shopware warehouses. Two control fields — NoWarehouseOverride and UpdateParent — together with the active mapping-filter option, select the path.
ID Format
Manual Sync ID Format
The standalone Add and Update collections are triggered for a single record by entering the iPaaS.com inventory record identifier for the transfer. The inventory record carries a reference to its parent product (used to resolve the linked Shopware product) and a location (used to resolve the Shopware warehouse on the warehouse path). Inventory records are also processed automatically when an iPaaS.com inventory add or change targets this Shopware subscription through an Outbound Data Flow.
External ID Format
When the Add collection writes an inventory record, the integration stores an external-id link that pairs the Shopware product-warehouse (inventory) record identifier with the Shopware product identifier, in the form productWarehouseRecordId|productId — for example 9f8b7c3a2d1e4a659b2f|5d3c2a1b9e7f4c1a8d9b. The Update collection relies on that stored link to locate the correct inventory record; it does not carry a separate product mapping because the product is resolved from the stored link. On the warehouse path the link can also be established automatically before the write when a matching Shopware warehouse record already exists for the same product and location (see the record-matching step in the Integration Flow), so an inventory record that already exists in Shopware is updated in place rather than duplicated.
Deleted Record Support
Inbound delete is not offered as a standalone inventory collection. There is no Delete Product Inventory collection in this family; when a product is removed, its inventory is reconciled through the parent product delete rather than through an independent inventory delete. As a result, this documentation covers the Add and Update flows only.
Custom Field Support
These standalone inventory collections do not read iPaaS.com custom fields. The stock value comes directly from the inventory record's available quantity, and the path-control values are supplied as static mappings (see the Mappings section). No named custom fields need to exist on the source record for these collections to run.
Mapping Collection Status
Both collections in this family are Enabled.
Trigger Events
Add Shopware Product Inventory FROM iPaaS.com: Transferred from iPaaS.com to Shopware when an iPaaS.com inventory record is added for a linked product and targets this Shopware subscription through an Outbound Data Flow, or when triggered manually by entering the inventory record identifier.
Update Shopware Product Inventory FROM iPaaS.com: Transferred when an existing iPaaS.com inventory record changes for a linked product, through the same Outbound Data Flow or Manual Sync path.
These collections are not initialized in bulk; they transfer on the inventory add or change event.
Duplicate or Conflicting Mappings
Product inventory flows into Shopware from iPaaS.com; there is no opposite-direction "TO iPaaS.com" product inventory collection paired with these, so there are no opposing collections that write the same record in the other direction. Within the integration, the collections that write the same Shopware inventory record are complementary and should not be run so that they compete:
Add Shopware Product Inventory FROM iPaaS.com writes the initial inventory record and establishes the external-id link the Update collection relies on.
Update Shopware Product Inventory FROM iPaaS.com maintains the inventory record the Add collection created.
The child inventory collection that rides the full product transfer (documented in the Shopware Product From iPaaS.com Mapping Documentation) writes the same product stock as part of a product transfer.
Subscribers or their MiSP should decide whether product stock is driven by the standalone inventory transfers or by the full product transfer, and keep the warehouse-versus-non-warehouse choice consistent across the pair, so the same stock is not written twice in conflicting ways. The NoWarehouseOverride / UpdateParent control fields and the active mapping-filter option must agree on a single path (see the Mappings section).
Supported Child Collections
These are standalone collections with no child collections of their own. On the warehouse path they write a single product-warehouse record per linked location; on the non-warehouse path they relay a parent-product stock update through the product stock-refresh collection described in the Shopware Product From iPaaS.com Mapping Documentation.
Shopware Caveats
Warehouse-level stock is a premium Shopware feature (Advanced Stock Management / multi-warehouse). Subscribers without it cannot write warehouse-scoped stock and should use the non-warehouse (parent-product) path so stock reaches the product.
The linked Shopware product must already exist and be linked in iPaaS.com. On the warehouse path a linked Shopware warehouse must also resolve from the iPaaS.com location. Records for unlinked products (or, on the warehouse path, unlinked locations) are skipped by the mapping filter rather than failing the whole transfer.
Inventory writes bypass the Index Behavior Header: Shopware re-indexing is never deferred for an inventory transfer, even when the indexing-deferral behavior is enabled for product writes.
On the non-warehouse path the integration applies a stock-only update to the parent product; other product fields are left untouched.
iPaaS.com Caveats
The stock written to Shopware is the available quantity on the iPaaS.com inventory record at the time of the transfer.
The non-warehouse path is selected by mapping NoWarehouseOverride to "true" (or "y"); with NoWarehouseOverride set to "true", UpdateParent must also be mapped to an explicit "true" or "false" value. Leaving UpdateParent empty on the non-warehouse path causes the transfer to error when it evaluates the flag.
Subscribers or their MiSP should stagger large manual inventory jobs and rely on the configured throttle limits to avoid overrunning the Shopware API during bulk stock transfers.
Setup Requirements
For automatic transfer, the subscription's Outbound Data Flows must be configured so that iPaaS.com inventory add and change events for linked products target this Shopware subscription. Before enabling the family, subscribers or their MiSP should:
Decide the inventory path (warehouse vs. non-warehouse) and set the NoWarehouseOverride / UpdateParent control fields and the active mapping-filter option to agree on that path.
Confirm the linked Shopware product exists and is linked in iPaaS.com, and — on the warehouse path — that the Shopware warehouse is linked to the iPaaS.com location.
Confirm the Outbound Data Flows that carry inventory events are configured and enabled.
Integration Flow
An iPaaS.com inventory record is added or changes for a product, and the event targets this Shopware subscription — automatically through an Outbound Data Flow or by Manual Sync.
The collection's mapping filter decides whether the record is processed: the warehouse path passes a record only when both a linked Shopware warehouse (resolved from the iPaaS.com location) and a linked Shopware product exist; the non-warehouse path passes any record whose product is linked, ignoring the warehouse requirement.
On the warehouse path, before writing, if the inventory record is not already linked to a Shopware record the integration attempts to match it to an existing Shopware warehouse record for the same product and location; when a match is found it stores the link so the existing record is updated in place rather than a duplicate being created. If a match is found but the link cannot be stored, the transfer fails to prevent a silent duplicate.
On the warehouse path, the mapped stock is written to the Shopware product-warehouse record — created by the Add collection, updated by the Update collection.
On the non-warehouse path (NoWarehouseOverride "true"), the warehouse write is bypassed: with UpdateParent "false" a stock-only update is applied directly to the parent product; with UpdateParent "true" the parent product is flagged for a secondary, stock-only update and re-transferred through the product stock-refresh collection so the stock lands at the product level.
On a successful Add, the Shopware product-warehouse identifier is stored (paired with the product id) so subsequent Update transfers locate the same inventory record.
Mappings
Add Shopware Product Inventory FROM iPaaS.com
Mapping Filter
//Option 1 - Requires Shopware warehouses, only transfer to linked iPaaS locations
var locationId = await GetWareHouseIdByIpaasLocationId(LocationId);
if(locationId != null && locationId != ""){
//Only add to linked products
var externalId = await GetExternalIdAsync(ParentId.ToString(), "Product", SpaceportSystemId);
if(externalId != null && externalId != ""){
return true;
}
}
return false;//Option 2 - Filter does not require Shopware warehouses, used to only update Shopware product stock for linked iPaaS products
//Note: A mapping must exist passing "true" to NoWarehouseOverride
//Note: A mapping must exist passing "true" to UpdateParent
//Shopware warehouses will not be updated in this configuration and only Product stock levels will be modified
var externalId = await GetExternalIdAsync(ParentId.ToString(), "Product", SpaceportSystemId);
if(externalId != null && externalId != ""){
return true;
}
return false;//Consult with your MISP to determine the best logic for your implementationFilter Description. This collection ships with two configurable options; subscribers or their MiSP choose one and should consult their MiSP for the best logic. Option 1 (warehouse path, active as shipped) resolves the Shopware warehouse linked to the iPaaS.com location and passes a record only when both that warehouse and the linked Shopware product exist; inventory for unlinked locations or unlinked products is skipped. Option 2 (non-warehouse path) drops the warehouse requirement and passes any record whose product is linked in Shopware, updating only product-level stock; it requires mappings passing "true" to both NoWarehouseOverride and UpdateParent. To use Option 2, comment out Option 1 so the second block is active. The filter does not throw and pins no environment-specific value.
Description: Writes the initial inventory record for a product, on either the warehouse path or the parent-product (non-warehouse) path.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Shopware) | Description |
Static |
| NoWarehouseOverride | optional — set to "true"/"y" to bypass the warehouse write and apply stock directly to the product; its setting must match the active filter option. |
Dynamic Formula | Linked product (parent id) | ProductId | required — resolves the linked Shopware product the inventory belongs to from the iPaaS.com parent product id. |
Field | QtyAvailable | Stock | required — the available inventory quantity written to Shopware. |
Static |
| UpdateParent | optional — set to "true"/"y" (with NoWarehouseOverride "true") to route the stock update to the parent product through the product stock-refresh collection. On the non-warehouse path this field must be mapped to an explicit value. |
Dynamic Formula | Shopware warehouse (from iPaaS.com location) | WarehouseId | optional — resolves the Shopware warehouse on the warehouse path only; requires the premium warehouse feature. |
Warehouse-level stock requires the premium Shopware warehouse feature (Advanced Stock Management). Subscribers without it should use the non-warehouse path — NoWarehouseOverride "true" with UpdateParent "true" — so stock reaches the parent product. Inventory writes bypass the Index Behavior Header.
Update Shopware Product Inventory FROM iPaaS.com
Mapping Filter
//Option 1 - Requires Shopware warehouses, only transfer to linked iPaaS locations
var locationId = await GetWareHouseIdByIpaasLocationId(LocationId);
if(locationId != null && locationId != ""){
//Only add to linked products
var externalId = await GetExternalIdAsync(ParentId.ToString(), "Product", SpaceportSystemId);
if(externalId != null && externalId != ""){
return true;
}
}
return false;//Option 2 - Filter does not require Shopware warehouses, used to only update Shopware product stock for linked iPaaS products
//Note: A mapping must exist passing "true" to NoWarehouseOverride
//Note: A mapping must exist passing "true" to UpdateParent
//Shopware warehouses will not be updated in this configuration and only Product stock levels will be modified
var externalId = await GetExternalIdAsync(ParentId.ToString(), "Product", SpaceportSystemId);
if(externalId != null && externalId != ""){
return true;
}
return false;//Consult with your MISP to determine the best logic for your implementationFilter Description. This collection updates inventory on an existing product and ships with the same two options as the Add collection. Option 1 (warehouse path, active as shipped) passes a record only when both the linked Shopware warehouse and the linked Shopware product exist; inventory for unlinked locations or unlinked products is skipped. Option 2 (non-warehouse path) passes any record whose product is linked, updating only product-level stock, and requires mappings passing "true" to both NoWarehouseOverride and UpdateParent. To use Option 2, comment out Option 1. The filter does not throw and pins no environment-specific value.
Description: Updates inventory on an existing product for subsequent stock changes, on either the warehouse path or the parent-product (non-warehouse) path. The product is resolved from the stored external-id link, so this collection carries no separate product mapping.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Shopware) | Description |
Static |
| NoWarehouseOverride | optional — set to "true"/"y" to bypass the warehouse write and apply stock directly to the product; its setting must match the active filter option. |
Field | QtyAvailable | Stock | required — the available inventory quantity written to Shopware. |
Static |
| UpdateParent | optional — set to "true"/"y" (with NoWarehouseOverride "true") to route the stock update to the parent product through the product stock-refresh collection. On the non-warehouse path this field must be mapped to an explicit value. |
Dynamic Formula | Shopware warehouse (from iPaaS.com location) | WarehouseId | optional — resolves the Shopware warehouse on the warehouse path only; requires the premium warehouse feature. |
Warehouse-level stock requires the premium Shopware warehouse feature. Subscribers without it should use the non-warehouse path. Inventory writes bypass the Index Behavior Header.
Error Handling
Errors surface in Dashboard / Integration Monitoring / Error Logs.
Non-warehouse path with UpdateParent unmapped: when NoWarehouseOverride is "true" but UpdateParent is left empty, the transfer errors as it evaluates the flag. Resolution: on the non-warehouse path always map UpdateParent to an explicit "true" or "false".
Product not linked: the filter cannot resolve the linked Shopware product, so the record is skipped. Resolution: confirm the product was created and linked in iPaaS.com before transferring its inventory.
Warehouse path active without the warehouse feature: no Shopware warehouse resolves from the iPaaS.com location, so records are skipped on the warehouse path. Resolution: switch to the non-warehouse path (Option 2) with NoWarehouseOverride / UpdateParent set, or enable the premium warehouse feature.
Unable to link inventory to an existing Shopware record: the integration matched an existing Shopware warehouse record for the product and location but could not store the link, so a duplicate inventory record may result. Resolution: re-check the product's linkage in iPaaS.com and retry; if the error persists, contact iPaaS.com Support.
Shopware API temporarily unavailable: the transfer fails at write time. Resolution: retry by triggering a new transfer from iPaaS.com.
Testing & Validation
Test Scenarios
Add inventory on the warehouse path (Option 1) for a linked product with a linked warehouse and confirm the stock lands on the Shopware product-warehouse record.
Update the same inventory record and confirm the changed stock lands on the existing record rather than creating a duplicate.
Add and update inventory on the non-warehouse path (Option 2, NoWarehouseOverride / UpdateParent "true") and confirm stock reaches the parent product.
Transfer inventory for a product that is not linked and confirm the record is skipped without affecting other stock.
Transfer inventory on the non-warehouse path with UpdateParent left unmapped and confirm the error surfaces in Dashboard / Integration Monitoring / Error Logs.
Validation Checklist
The inventory path is decided and the NoWarehouseOverride / UpdateParent control fields and the active filter option agree on a single path.
The linked Shopware product exists and is linked in iPaaS.com, and — on the warehouse path — the Shopware warehouse is linked to the iPaaS.com location.
On the non-warehouse path, UpdateParent is mapped to an explicit value.
The source of truth for product stock has been decided so the standalone inventory transfers and the full product transfer do not write the same stock in conflicting ways.
Warehouse-versus-non-warehouse behavior has been validated in a staging environment before being relied on in production.
Additional Notes
The same product stock can be written as a child of the full product transfer; that child collection, and the parent-relay (UpdateParent) stock-refresh behavior it feeds, are documented in the Shopware Product From iPaaS.com Mapping Documentation.
Warehouse-level stock requires the premium Shopware warehouse feature (Advanced Stock Management); subscribers without it use the non-warehouse (parent-product) path. The warehouse-versus-non-warehouse choice should be validated in a staging environment before being relied on in production.