Summary
Stock figures recorded in iPaaS.com are written into Adobe Commerce/Magento 2 for product variants that already exist in the Magento store. For each iPaaS.com inventory record processed, one inventory row is written carrying the quantity on hand and the in-stock flag for the Magento inventory source that the record's location translates to.
In Adobe Commerce/Magento 2 the variant is the item shoppers actually buy and the item that actually holds sellable stock. The configurable product it sits beneath is only a container, and Magento decides whether that container can be purchased from the stock held on its variants. The quantities written here are therefore the figures that drive storefront availability.
Two standalone collections cover this — one for creating inventory rows and one for refreshing rows that already exist. The transfer is unidirectional; stock is never read back out of Magento.
ID Format
Manual Sync ID Format
Enter the iPaaS.com Product Inventory record identifier — the internal numeric identifier of the inventory record in iPaaS.com, for example 72104.
This is not the variant SKU and it is not the variant record identifier. Entering either of those will not resolve an inventory record.
External ID Format
These collections write inventory against a variant that has already been linked to Adobe Commerce/Magento 2, so they do not mint a new external-ID record for the variant. The external-ID record created by the variant transfer is what the add collection reads to resolve the Magento SKU, and it remains the mechanism routing later inventory transfers of the same variant to the correct Magento record.
Deleted Record Support
Outbound delete is not supported for inventory. Removing an inventory record in iPaaS.com does not remove the corresponding inventory row from Adobe Commerce/Magento 2, and delete mappings are not included in the default templates for these collections.
Inventory sources themselves cannot be deleted in Adobe Commerce/Magento 2 once created — they can only be disabled. See the caveats below.
Custom Field Support
Neither collection reads a custom field. Unlike the standalone product inventory update collection, the variant update collection applies no kit-component totalling, so the Kit Parent custom field has no effect here — the location's own available quantity is always used.
Mapping Collection Status
Status: Enabled. Both collections ship enabled. The add collection's mapping filter is a genuine business condition rather than a disabling guard, so records that satisfy it are processed as soon as the outbound flow is enabled or a Manual Sync is run.
Trigger Events: Creation or update of Product Inventory records in iPaaS.com for variants that already exist in Magento, plus Manual Sync on demand.
Automatic outbound transfers are enabled on the subscription's Outbound Data Flows page. Until that flow is enabled, no inventory rows are sent automatically. Manual Sync is always available regardless, and because these collections stand on their own it is the standard way to push a single corrected stock figure, seed stock during implementation, or recover inventory missed while the outbound flow was disabled.
Duplicate or Conflicting Mappings
Several other collections write inventory into Adobe Commerce/Magento 2 and can act on the same variants and the same inventory sources:
Add Adobe Commerce/Magento 2 Simple Associated Product Variant Inventory FROM iPaaS.com and Update Adobe Commerce/Magento 2 Simple Associated Product Variant Inventory FROM iPaaS.com write variant inventory as children of the configurable product transfers, for the same variants and the same sources.
Update Adobe Commerce/Magento 2 Simple Associated Product Variant Inventory Totals FROM iPaaS.com refreshes a variant's aggregate stock totals rather than its per-source rows.
Update Adobe Commerce/Magento 2 Configurable Product Inventory Stock Status FROM iPaaS.com refreshes the configurable parent's stock status.
The standalone product inventory collections do the same work for products rather than variants.
Because these collections target the same Magento inventory sources, subscribers or their MiSP should review their filters and their Add and Update settings together before enabling or modifying any of them. Enabling several inventory paths against the same sources without reviewing them leaves the last transfer to run deciding the stock figure in Magento.
Duplicate matching
This integration implements no selectable collision-handling methods, and the behavior is not configurable on these collections. Adobe Commerce/Magento 2 applies every inventory transfer as an upsert keyed on the variant Sku plus the inventory SourceCode. Two inventory records that resolve to the same SKU and the same source code write to the same row, and the later transfer wins.
Unmapped field overwrite risk
Inventory is written as a full overwrite of the quantity at the target source. The value sent replaces the value in Magento rather than being added to it, and there is no incremental or delta mode. Subscribers or their MiSP should treat iPaaS.com as the system of record for stock at any source these collections target, and should avoid adjusting those quantities directly in the Magento admin, because the next transfer will replace them.
The fields at risk are the ones these collections map: the inventory Quantity and Status at the source resolved by SourceCode, on the variant identified by Sku. No other variant data is written by these collections.
The mitigation is a DestinationValue. Where a Magento field must hold a specific value that the source system does not supply, set a DestinationValue on that mapping so the integration writes the value chosen there instead of taking it from the source.
Supported Child Collections
None. Both collections are standalone. Neither has a parent collection, neither runs beneath a product transfer, and neither has child collections — each writes a single inventory row per record and has no subordinate data to contribute.
System Caveats
Adobe Commerce/Magento 2 Caveats
The product variant must already exist in Magento. These collections resolve an existing Magento variant and write inventory against it; they never create one. Variants are created by the product variant collections, which must run first.
The inventory source must already exist in Magento. Magento validates the source code before applying any inventory change and will not create a source on demand. Sources are configured under Multi Source Inventory in the Magento admin, and must be in place before these collections are enabled.
Source codes are case-sensitive and must match Magento exactly. This is the single most damaging misconfiguration in this transfer. A case mismatch causes the Magento inventory indexer to fail, and a failed inventory index can hide all products in the Magento admin until it is corrected and reindexed. Location values are sent in uppercase, so the corresponding Magento source codes are normally uppercase as well. Copy source codes directly from the Magento admin rather than retyping them.
Inventory sources cannot be deleted once created — only disabled. A source created by mistake, or created with the wrong code, is permanent. Confirm source codes are correct before the first transfer runs rather than relying on cleaning them up afterwards.
Inventory writes are subject to Magento's API limits. Larger catalogs and large catch-up runs can encounter Adobe Commerce/Magento 2 request-array and page-size limits. Stagger large manual catch-up runs rather than issuing them concurrently.
iPaaS.com Caveats
The location-to-source mapping must be one-to-one. Each iPaaS.com location must translate to exactly one Magento inventory source, and no two locations may translate to the same source. Where several iPaaS.com locations genuinely need to feed a single Magento source, the transfer must be filtered down to one location and the quantities combined before transfer. Configuring a many-to-one translation produces incorrect stock, because each location's write overwrites the previous one rather than adding to it.
A location with no matching translation row sends no source code. An unmatched Lookup Translation does not raise an error — it simply produces no value. The inventory row is then written without a source code and is rejected by Adobe Commerce/Magento 2, and that rejection is reported under Dashboard / Integration Monitoring / Error Logs.
The available quantity must be present and numeric. Both the quantity and the in-stock flag are produced from the iPaaS.com available quantity for the location being processed, so a missing or non-numeric value leaves the row without a usable quantity and it does not land.
The variant's external-ID record must be intact. The Magento SKU is resolved from the record linking the iPaaS.com variant to its Magento counterpart. If that link is missing, the add collection's mapping filter skips the record entirely.
Integration-Specific Caveats
The two collections round quantities differently. The add collection sends the iPaaS.com available quantity through unchanged, with no whole-unit floor. The update collection rounds the quantity down to a whole number. The same fractional source quantity can therefore produce different storefront availability depending on which collection processed it, and both paths can be enabled at once. Subscribers whose iPaaS.com stock is tracked in fractional units should validate in a staging environment how Adobe Commerce/Magento 2 treats a decimal quantity at their sources before relying on it in production.
The in-stock flag follows the quantity. Status is derived from the same figure used for the quantity, and is set to out of stock when that figure is zero or less. On the add collection, because no floor is applied, a fractional quantity above zero reads as in stock even where the remaining balance is less than one sellable unit. Subscribers who need stock to remain purchasable at zero, for example for backorder or pre-order variants, should be aware that this marks those variants out of stock at the affected source; backorder handling is configured in Adobe Commerce/Magento 2 itself.
No kit-component totalling is applied. Unlike the standalone product inventory update collection, the variant update collection always uses the location's own available quantity. A kit flag on the record has no effect on this transfer.
Aggregate totals and the configurable parent's stock status are not refreshed by these transfers. An inventory-only transfer writes the per-source rows for the variant. It does not recalculate the variant's aggregate stock totals, and it does not recalculate the configurable parent's stock status. The variant inventory totals and configurable stock status collections cover those, and both ship disabled behind an always-false condition in their mapping filters that must be removed before they will process any records.
Setup Requirements
Adobe Commerce/Magento 2 Configuration
Create every required inventory source under Multi Source Inventory, confirming the exact spelling and casing of each source code before saving, since sources cannot be deleted afterwards.
Confirm the resulting source codes in the Magento admin and copy them directly rather than retyping them.
iPaaS.com Configuration
Transfer the iPaaS.com Locations that correspond to those sources.
Review the source code Lookup Translation and edit each row in place, so that there is exactly one row per iPaaS.com location the transfer will process. See the Lookup Translations section below for how the match condition works.
Confirm the location-to-source mapping is one-to-one, with no two iPaaS.com locations pointing at the same Magento inventory source.
Transfer the product variants themselves and confirm they exist in Adobe Commerce/Magento 2, since inventory records for variants that have not transferred are skipped by the add collection's filter.
Review these collections alongside the variant inventory collections that run beneath the configurable product transfers, the variant inventory totals collection, and the configurable stock status collection, so that only the intended inventory paths are active against the same sources.
Enable the outbound flow for Adobe Commerce/Magento 2 inventory on the subscription's Outbound Data Flows page.
Full step-by-step setup instructions are in the Adobe Commerce/Magento 2 Installation Instructions article.
Integration Flow
The iPaaS.com inventory record is checked against the add collection's mapping filter, which confirms the variant the record belongs to has already been transferred to Adobe Commerce/Magento 2. A record whose variant has not yet transferred is skipped at this point and goes no further. The update collection carries no such filter; it is scoped by the stored link instead.
For a record that passes, the Magento SKU of that variant is resolved from the record iPaaS.com holds linking the two systems.
The iPaaS.com location on the record is translated into an Adobe Commerce/Magento 2 inventory source code. A location that does not translate produces no source code, and the row is rejected by Magento.
The quantity and the in-stock flag are produced from the iPaaS.com available quantity for that location — floored on the update collection, sent unchanged on the add collection — and written as one inventory row for that variant and that source.
Magento applies the row as an upsert and reindexes the affected inventory.
Mappings
Add Adobe Commerce/Magento 2 Standalone Product Variant Inventory FROM iPaaS.com
iPaaS.com data type: Product Variant Inventory
Mapping Filter
var external = await GetExternalIdAsync(ParentId, "Product Variant", SpaceportSystemId);
if(!IsEmpty(external)){return true;} else {return false;}This collection processes an inventory record only when the product variant that record belongs to has already been transferred to Adobe Commerce/Magento 2. The filter performs that check by looking for the Magento identifier iPaaS.com holds against the variant, and lets the record through only when one is present.
A record that does not pass is skipped, not failed. It is not sent to Magento, it does not raise an error, and it does not appear in the Error Logs. The practical consequence is that stock which appears to be missing in Adobe Commerce/Magento 2 is usually a sign that the variant transfer has not yet run, not that inventory is failing. Once the variant exists in Magento, the next inventory transfer for it is processed normally, and stock recorded while the variant was still absent should be re-sent.
This filter is what allows the collection to stand on its own. The variant inventory collections that run beneath a configurable product transfer inherit the variant from the transfer above them and correctly carry no such condition. Do not remove it — doing so would send inventory rows naming variants Magento does not have, which it rejects.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Adobe Commerce/Magento 2) | Description |
Dynamic Formula |
| Sku | Required. Identifies which Magento variant the inventory row belongs to. Resolved from the variant the inventory record hangs from rather than read from a SKU field on the record. Together with the source code it is the key Magento uses to decide which inventory row to write. |
Lookup Translation | Lookup Translation: M2 Product Inventory Source Code From iPaaS | SourceCode | Required. Resolves which Magento inventory source the variant's quantity is written to. An inventory row cannot be written without a valid source code. |
Field | QtyAvailable | Quantity | Required. The quantity on hand for the location being processed, sent through unchanged with no whole-unit floor and no kit-component totalling. Magento will not accept an inventory row without a quantity. |
Dynamic Formula |
| Status | Required. The in-stock flag Magento holds against the variant at that source. Accepts only 1 for in stock and 0 for out of stock. Because no floor is applied here, a fractional quantity above zero reads as in stock. |
Update Adobe Commerce/Magento 2 Standalone Product Variant Inventory FROM iPaaS.com
iPaaS.com data type: Product Variant Inventory
This collection carries no mapping filter. The absence is deliberate and should not be read as a gap: the collection is scoped by the stored link rather than by a condition, so a variant inventory record is updated in Magento only where that record is already linked to an inventory row in the store from an earlier transfer. Stock changes for a variant that has never been transferred fall outside its scope and are not sent. Subscribers or their MiSP should not add a variant-existence condition here — the paired add collection carries that condition, and duplicating it adds no protection.
This collection also maps no Sku of its own. The variant SKU and the inventory source that identify the row to overwrite come from the link established when the variant and its inventory were first transferred.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Adobe Commerce/Magento 2) | Description |
Lookup Translation | Lookup Translation: M2 Product Inventory Source Code From iPaaS | SourceCode | Required. Resolves which Magento inventory source the quantity is written to. Together with the variant's SKU it identifies the single inventory row Magento overwrites. |
Dynamic Formula |
| Quantity | Required. The available quantity for the location being processed, rounded down to a whole number because Magento tracks stock in whole units, so 4.7 is sent as 4. No kit-component totalling is applied. |
Dynamic Formula |
| Status | Required. Derived from the same floored figure used for the quantity, and set to 0 for out of stock when it rounds down to zero or less, 1 otherwise. |
Lookup Translations
M2 Product Inventory Source Code From iPaaS
Used by the SourceCode mapping on both collections. This is the same translation used by the standalone product inventory collections, so a change made here affects both product and variant inventory transfers.
The source side of this translation is not a plain location name. Each row matches the inventory record's location by resolving an iPaaS.com location name to its location identifier and comparing it to the location on the record. The destination side is the Magento inventory source code that location should write to.
Source Value | Destination Value | Notes |
Location matches the iPaaS.com location named MAIN | MAIN | Example row — replace both sides. |
Location matches the iPaaS.com location named EAST | EAST | Example row — replace both sides. |
Location matches the iPaaS.com location named STORAGE | STORAGE | Example row — replace both sides. |
Placeholder value — replace during implementation: the shipped location names MAIN, EAST and STORAGE, and the Magento source codes they point at, are example values carried by the template and are almost certainly not the names used in a given subscriber's environment.
What subscribers or their MiSP replace is the location name inside the match condition on the source side, and the Magento inventory source code on the destination side — not the row as a whole. Replacing a source-side match condition with a bare location name breaks the lookup, because the row no longer evaluates against the record's location and no source code is produced. Each row should be edited in place, and rows added or removed so that there is exactly one row per iPaaS.com location the transfer will process.
If an inventory record's location does not match any row, no source code is produced for that record. The inventory row is then written without a source code and is rejected by Adobe Commerce/Magento 2, so the stock figure never lands.
Error Handling
The full catalog of messages this integration produces, with causes and resolutions, is in the Adobe Commerce/Magento 2 Error Messages article. The conditions most often seen on this transfer are:
An inventory row rejected for a missing or invalid source code. The record's location matched no row in the source code translation, or the source code does not exist in Magento. Resolution: add or correct the translation row, and confirm the source exists under Multi Source Inventory with exactly that code and casing.
An inventory row rejected for an unknown SKU. The variant does not exist in Magento under the resolved SKU. Resolution: transfer the variant first, then re-send the inventory.
A record silently skipped. The add collection's filter found no Magento identifier for the variant. This produces no error and no log entry. Resolution: confirm the variant has transferred, then re-send the inventory record.
A failed inventory index in Magento. Caused by a source code whose casing does not match Magento exactly. This can hide all products in the Magento admin until corrected and reindexed. Resolution: correct the source code casing and reindex in Magento.
Errors are reported under Dashboard / Integration Monitoring / Error Logs.
Testing & Validation
Test Scenarios
Manually sync a variant inventory record using its iPaaS.com Product Inventory record identifier and confirm the quantity and in-stock flag land at the expected Magento inventory source.
Confirm that entering a variant SKU or a variant record identifier instead does not resolve an inventory record.
Record a stock movement in iPaaS.com for a variant that already exists in Magento and confirm the storefront availability updates without a full product transfer running.
Attempt an inventory transfer for a variant that has not yet been transferred, and confirm the record is skipped silently with no entry in the Error Logs.
Transfer inventory for a location that has no row in the source code translation, and confirm Magento rejects the row and the rejection appears in the Error Logs.
Transfer a fractional quantity through each collection and compare the resulting Magento quantity, confirming the add collection sends it unchanged and the update collection rounds it down.
Set every variant of a configurable product to zero quantity and confirm the storefront treats the configurable parent as unpurchasable, noting that the parent's own stock status is not refreshed by this transfer.
Adjust a variant quantity directly in the Magento admin, re-run the transfer, and confirm the iPaaS.com figure replaces it.
Validation Checklist
Every inventory source the transfer targets exists in Adobe Commerce/Magento 2 with the exact code and casing used in the translation.
The source code translation has exactly one row per iPaaS.com location the transfer will process, with the match condition intact on the source side.
The location-to-source mapping is one-to-one.
The example rows for MAIN, EAST and STORAGE have been replaced or removed.
The variants themselves have been transferred before inventory is enabled.
Only the intended inventory paths are enabled against the same sources.
Additional Notes
An inventory record whose variant has not yet transferred is skipped silently, with no error and no queued retry, so the stock figure is simply absent until inventory is re-sent after the variant exists.
A location that matches no translation row produces no error at the iPaaS.com end. The condition surfaces only as a Magento rejection, so a silently missing location is best detected by auditing the translation against the store's configured sources.
Inventory rows are always sent as a full overwrite of the quantity at the target source, so a stock figure adjusted directly in the Magento admin is replaced at the next transfer.
Because the configurable parent's purchasability is derived by Magento from its variants' stock, a variant transfer is what makes a configurable product available or unavailable on the storefront, even though the parent record itself is not written by these collections.
Validate dynamic formulas and translation changes in a staging environment before enabling automatic transfers in production.