Skip to main content

Shopware Product Variant Inventory From iPaaS.com Mapping Documentation

How standalone product variant inventory (warehouse-scoped stock) is written from iPaaS.com into Shopware — the Add and Update collections, the warehouse and non-warehouse paths, and the control fields that switch between them.

Summary

This documentation describes how iPaaS.com writes standalone product variant inventory — warehouse-scoped stock for a product variant — into Shopware. The family covers two collections that are triggered on their own when an iPaaS.com inventory record changes for a linked variant: an Add collection that writes the initial inventory record and an Update collection that maintains it. These are the standalone variant inventory transfers; the same inventory data can alternatively be written as part of the variant transfer through the child variant 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 for the variant, 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 variant, 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 variant (used to resolve the linked Shopware variant) 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 variant's 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. The variant itself is identified by an external id that carries both the variant and its parent product ids. 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 variant 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 variant inventory collection. There is no Delete Product Variant Inventory collection in this family; when a variant is removed, its inventory is reconciled through the parent variant 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 variant 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 Variant Inventory FROM iPaaS.com: Transferred from iPaaS.com to Shopware when an iPaaS.com inventory record is added for a linked variant and targets this Shopware subscription through an Outbound Data Flow, or when triggered manually by entering the inventory record identifier.

  • Update Shopware Product Variant Inventory FROM iPaaS.com: Transferred when an existing iPaaS.com inventory record changes for a linked variant, 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

Variant inventory flows into Shopware from iPaaS.com; there is no opposite-direction "TO iPaaS.com" variant 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 Variant Inventory FROM iPaaS.com writes the initial inventory record and establishes the external-id link the Update collection relies on.

  • Update Shopware Product Variant Inventory FROM iPaaS.com maintains the inventory record the Add collection created.

  • The child variant inventory collection that rides the variant transfer (documented in the Shopware Product From iPaaS.com Mapping Documentation) writes the same variant stock as part of a variant transfer.

Subscribers or their MiSP should decide whether variant stock is driven by the standalone inventory transfers or by the variant 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 variant-level stock update through the variant 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 (variant-level) path so stock reaches the variant.

  • On the warehouse path, a linked Shopware warehouse must resolve from the iPaaS.com location before the Add collection can create the record — the Add transfer is rejected when no warehouse is linked. The linked Shopware variant must also already exist and be linked in iPaaS.com. Records for unlinked variants (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 and variant writes.

  • On the non-warehouse path the integration applies a stock-only update to the variant; other variant 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.

  • The ProductId mapping must resolve the linked variant. On the non-warehouse path the variant is identified from this value, so a variant that is not linked cannot receive stock through the parent-relay path.

  • 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 variants 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 variant 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

  1. An iPaaS.com inventory record is added or changes for a variant, and the event targets this Shopware subscription — automatically through an Outbound Data Flow or by Manual Sync.

  2. 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 variant exist; the non-warehouse path passes any record whose variant is linked, ignoring the warehouse requirement.

  3. 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 variant 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.

  4. On the warehouse path, the mapped stock is written to the Shopware product-warehouse record for the variant — created by the Add collection (which requires a linked warehouse), updated by the Update collection.

  5. On the non-warehouse path (NoWarehouseOverride "true"), the warehouse write is bypassed: with UpdateParent "false" a stock-only update is applied directly to the variant; with UpdateParent "true" the variant is flagged for a secondary, stock-only update and re-transferred through the variant stock-refresh collection so the stock lands at the variant level.

  6. On a successful Add, the Shopware product-warehouse identifier is stored (paired with the variant's product id) so subsequent Update transfers locate the same inventory record.

Mappings

Add Shopware Product Variant 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 Variant", 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 Variant", SpaceportSystemId);
if(externalId != null && externalId != ""){
    return true;
}
return false;//Consult with your MISP to determine the best logic for your implementation

Filter Description. The variant counterpart of the Add Product Inventory filter. 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 variant exist; inventory for unlinked locations or unlinked variants is skipped. Option 2 (non-warehouse path) drops the warehouse requirement and passes any record whose variant is linked in Shopware, updating only variant-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 variant, on either the warehouse path or the variant-level (non-warehouse) path.

Mapping Type

Source Field (iPaaS.com)

Destination Field (Shopware)

Description

Dynamic Formula

Shopware warehouse (from iPaaS.com location)

WarehouseId

required on the warehouse path — resolves the Shopware warehouse for the variant stock; the Add is rejected when no warehouse is linked. Requires the premium warehouse feature.

Dynamic Formula

Linked variant (parent id)

ProductId

required — resolves the linked Shopware variant; the external id carries both the variant and parent product ids.

Field

QtyAvailable

Stock

required — the available inventory quantity written to the variant.

Static

"false"

UpdateParent

optional — set to "true"/"y" (with NoWarehouseOverride "true") to apply stock at the variant level via the variant stock-refresh collection. On the non-warehouse path this field must be mapped to an explicit value.

Static

"false"

NoWarehouseOverride

optional — set to "true"/"y" to bypass the warehouse write; align with the active filter option.

Placeholder value — replace during implementation: the static "false" on UpdateParent and NoWarehouseOverride is the default for warehouse-enabled subscriptions; subscribers tracking stock at the variant level should set both to "true". Inventory writes bypass the Index Behavior Header.

Update Shopware Product Variant 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 Variant", 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 Variant", SpaceportSystemId);
if(externalId != null && externalId != ""){
    return true;
}
return false;//Consult with your MISP to determine the best logic for your implementation

Filter Description. The variant counterpart of the Update Product Inventory filter. Option 1 (warehouse path, active as shipped) passes a record only when both the linked Shopware warehouse and the linked Shopware variant exist; inventory for unlinked locations or unlinked variants is skipped. Option 2 (non-warehouse path) passes any record whose variant is linked, updating only variant-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 variant inventory for subsequent stock changes, on either the warehouse path or the variant-level (non-warehouse) path.

Mapping Type

Source Field (iPaaS.com)

Destination Field (Shopware)

Description

Dynamic Formula

Shopware warehouse (from iPaaS.com location)

WarehouseId

optional — resolves the Shopware warehouse on the warehouse path only; requires the premium warehouse feature. On the warehouse path the record is located from the stored external-id link.

Dynamic Formula

Linked variant (parent id)

ProductId

required — resolves the linked Shopware variant; on the non-warehouse path the variant to update is identified from this value.

Field

QtyAvailable

Stock

required — the available inventory quantity written to the variant.

Static

"false"

UpdateParent

optional — set to "true"/"y" (with NoWarehouseOverride "true") to apply stock at the variant level via the variant stock-refresh collection. On the non-warehouse path this field must be mapped to an explicit value.

Static

"false"

NoWarehouseOverride

optional — set to "true"/"y" to bypass the warehouse write; align with the active filter option.

Placeholder value — replace during implementation: the static "false" on UpdateParent and NoWarehouseOverride is the default for warehouse-enabled subscriptions; set both to "true" to track stock at the variant level. Inventory writes bypass the Index Behavior Header.

Error Handling

Errors surface in Dashboard / Integration Monitoring / Error Logs.

  • Warehouse path Add with no linked warehouse: the variant Add cannot create a warehouse record because no Shopware warehouse resolves from the iPaaS.com location, and the transfer is rejected. Resolution: link the Shopware warehouse to the iPaaS.com location, or switch to the non-warehouse path (Option 2).

  • 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".

  • Variant not linked: the filter cannot resolve the linked Shopware variant, so the record is skipped. Resolution: confirm the variant 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 (Update) or rejected (Add) on the warehouse path. Resolution: switch to the non-warehouse path 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 variant and location but could not store the link, so a duplicate inventory record may result. Resolution: re-check the variant'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 variant with a linked warehouse and confirm the stock lands on the Shopware product-warehouse record for the variant.

  • 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 variant.

  • Transfer inventory for a variant that is not linked and confirm the record is skipped without affecting other stock.

  • Transfer inventory on the warehouse path for a location with no linked Shopware warehouse and confirm the Add is rejected with an error 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 variant 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 variant stock has been decided so the standalone inventory transfers and the variant 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 variant stock can be written as a child of the variant 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 (variant-level) path. The warehouse-versus-non-warehouse choice should be validated in a staging environment before being relied on in production.

Did this answer your question?