Summary
commercetools products can be created and updated from iPaaS.com Product records through the Add/Update commercetools Product FROM iPaaS.com mapping collection and the five child collections beneath it, which carry the product's variants, its product-type attribute definitions, its option values, and its stock levels. Transfers run automatically once the matching outbound subscriptions are enabled under Outbound Data Flows, and on demand from the iPaaS.com Manual Sync page using the iPaaS.com Product ID. The purpose of this family is to drive the commercetools storefront catalogue from the upstream system of record that feeds iPaaS.com — a product, its variants, the attributes they need and their stock all move together in a single sequenced transfer.
ID Format
Manual Sync ID Format
Enter the iPaaS.com Product ID — the numeric identifier of the Product record on the iPaaS.com side. Because this family transfers data from iPaaS.com, the Manual Sync page expects the iPaaS.com record identifier, not a commercetools GUID.
Pattern: a numeric iPaaS.com Product ID. The value is the identifier shown on the Product record in iPaaS.com, and it is specific to your subscription — open the Product record to read it.
The integration uses this ID to retrieve the full Product record — including its variants, their option values, the attribute definitions those values need, and the inventory held at both product and variant level — and write the whole set to commercetools.
None of the five child collections has an independent Manual Sync entry point. Variants, attribute definitions, option values and inventory are transferred by running Manual Sync on the parent Product. Where a child's own description refers to a Manual Sync, it means a Manual Sync run on the parent collection above it.
External ID Format
After a successful write, iPaaS.com stores the commercetools identifier returned by commercetools as the external-ID link on the iPaaS.com record. commercetools issues record identifiers as 36-character GUIDs (UUIDs) — five groups of hexadecimal characters separated by hyphens in an 8-4-4-4-12 pattern. The value stored is therefore a commercetools identifier even though the transfer runs from iPaaS.com, and it is the opposite shape to the numeric ID entered on the Manual Sync page.
Links are recorded at several levels during a single product transfer:
The commercetools product identifier, stored against the iPaaS.com Product record. This link is what routes every subsequent transfer to an update of the existing commercetools product instead of creating a duplicate.
The commercetools variant identifier, stored against each iPaaS.com Product Variant record. This link decides whether a later transfer adds a new variant or updates the existing one.
The commercetools inventory entry identifier, stored against each iPaaS.com inventory record, at both product and variant level. This link causes a subsequent transfer to change the existing entry rather than creating a second one for the same item.
Attribute definitions and option values are not separately linked. Attribute definitions are matched inside the commercetools product type by their name; option values are matched within a variant by their attribute name. In both cases the link that governs re-transfer is the parent product's.
Deleted Record Support
Outbound delete is not supported for any collection in this family. Deleting an iPaaS.com Product, variant, attribute, option value or inventory record does not delete the corresponding record in commercetools, delete mappings are not included in the default mapping templates shipped with this integration, and deletions do not propagate in any direction. An attempted delete fails with the message "The method or operation is not implemented." — the exact string to search for in the Error Logs. Records that must be removed have to be deleted directly in commercetools.
Custom Field Support
This integration has no custom-field implementation for the Product family. None of the six collections reads or writes commercetools custom types or custom fields, and there is no conversion function for retrieving a custom field value on either side. Product, variant and inventory data that must be carried in a commercetools custom field cannot be transferred through these collections as shipped.
Note that commercetools product attributes are a different mechanism from commercetools custom fields, and product attributes are supported — see Add/Update commercetools Product Attribute FROM iPaaS.com and Add/Update commercetools Product Variant Option FROM iPaaS.com under Mappings.
Mapping Collection Status
Status: Enabled. All six collections ship enabled, and none of them has a mapping filter applied, so every Product transfer dispatched to this family is processed together with all of its variants, attributes, option values and inventory. The parent collection does carry an error condition that stops oversized products — see Add/Update commercetools Product FROM iPaaS.com under Mappings.
Trigger Events: Create and Update. All six collections ship with a sync type of Add/Update. Whether a given transfer creates a new commercetools record or updates an existing one is not decided by which event fired — it is decided by whether iPaaS.com already holds an external-ID link for the record.
Automatic Transfer
Records are dispatched to commercetools automatically when the subscriber enables the corresponding outbound subscriptions under Outbound Data Flows in the subscription configuration:
Mapping collection | Outbound subscriptions |
Add/Update commercetools Product FROM iPaaS.com | product/created, product/updated |
Add/Update commercetools Product Variant FROM iPaaS.com | product/variant/created, product/variant/updated |
Add/Update commercetools Product Inventory FROM iPaaS.com | product/inventory/created, product/inventory/updated |
Add/Update commercetools Product Variant Inventory FROM iPaaS.com | product/variant/inventory/created, product/variant/inventory/updated |
Add/Update commercetools Product Attribute FROM iPaaS.com | None — no automatic path exists |
Add/Update commercetools Product Variant Option FROM iPaaS.com | None — no automatic path exists |
Nothing transfers automatically until those subscriptions are enabled. Enabling the integration alone is not sufficient. Where they are not enabled, Manual Sync on the parent Product is the only transfer path.
Two collections have no outbound scope at all. Attribute definitions and variant option values cannot be dispatched by any event. They are written only as part of a parent transfer that carries them, which in practice means a parent Product transfer — either automatic through the product scopes above, or manual.
Manual Sync
Products are transferred on demand from the iPaaS.com Manual Sync page using the iPaaS.com Product ID, as described under ID Format above. Manual Sync is available on the parent collection regardless of any other configuration, and it carries the product's variants, attribute definitions, option values and inventory with it.
Duplicate or Conflicting Mappings
There is no inbound collection for any entity in this family — commercetools products, variants, attributes, option values and stock are not brought into iPaaS.com — so no collection operates on the same records in the opposite direction and no round-trip conflict is possible for product data.
The real overlap is within the outbound direction, between the two inventory collections in this family and their two standalone counterparts.
Overlapping Inventory Collections
Four collections in this integration write stock into commercetools, and they form two pairs:
Add/Update commercetools Product Inventory FROM iPaaS.com (documented here) and Update commercetools Product Inventory Standalone FROM iPaaS.com both write the same iPaaS.com Product Inventory data into the same commercetools inventory entries.
Add/Update commercetools Product Variant Inventory FROM iPaaS.com (documented here) and Add/Update commercetools Product Variant Inventory Standalone FROM iPaaS.com both write the same iPaaS.com Product Variant Inventory data into the same commercetools inventory entries.
Within each pair the two collections differ in role, not in destination. The collections documented here carry inventory alongside a product or variant publish, so stock arrives with the catalogue record. The standalone collections are stock-only paths that do not republish the product or variant, which is the appropriate choice for frequent stock adjustments. The standalone product-inventory collection is additionally limited to updates and will not create an entry that does not already exist.
Important: the outbound scopes are defined per data type and do not distinguish between the collections in a pair. If both members of a pair are enabled, a single iPaaS.com inventory change is processed twice. This integration performs no collision handling, so the later write wins and there is no single owner of the stock value. Decide before go-live which collection owns ongoing stock updates.
A further overlap exists between the two pairs. Product-level inventory and variant-level inventory are not duplicates of one another provided each item's stock is held in one place in iPaaS.com. Where iPaaS.com records stock at both the product and the variant level for the same item, the two can write competing values into the same commercetools inventory entry.
Unmapped Field Overwrite Risk
This risk applies to the parent Product collection only. It does not apply to either inventory collection in this family, whose update path sends only values that have actually changed.
When Add/Update commercetools Product FROM iPaaS.com updates an existing commercetools product, it always sends an instruction to set description_enUS and to change name_en, whether or not those fields are mapped in the collection. A field that is not mapped is sent with no value, and commercetools interprets that as an instruction to clear the field. Any existing value in these two fields on the commercetools product is therefore erased on every sync unless the field is mapped.
This applies to updates only. Creating a new commercetools product omits unmapped fields entirely and lets commercetools apply its own default, so the Add path carries no overwrite risk.
There are two ways to protect a field:
Map it from the iPaaS.com source. This is the correct approach whenever iPaaS.com genuinely holds the value.
Carry the existing commercetools value forward with DestinationValue. Where the value is maintained in commercetools and does not exist on the iPaaS.com side, add a Dynamic Formula mapping whose destination is the field to protect and whose source reads the current destination value. For example, a formula of
DestinationValue.description_enUSmapped to the description_enUS field returns the value already on the commercetools product and writes it back unchanged. Repeat this for each field you need to preserve.
Both description_enUS and name_en are mapped in the default mappings shipped with this integration, so a subscriber who accepts the defaults is protected. The risk arises when a mapping is removed, or when the source field is empty on the iPaaS.com Product record — an empty source value clears the destination value just as an absent mapping does.
The remaining product instructions — category assignment, tax category, publication state and attributes — are sent only when a value is present, so leaving those unmapped leaves the existing commercetools values alone.
Quantity Is the Exception on the Inventory Collections
Unmapped fields are not cleared on either inventory collection, with one important exception. An inventory update sends only the values that have actually changed, and sends no instruction for a value it has no mapping for, so inventory fields the collections do not map — restock lead time, expected delivery, cart quantity limits — are left as they are in commercetools. Quantity does not behave this way: when unmapped it is not left alone, it is sent as zero. Removing the Quantity mapping on the strength of the general rule above will zero the stock level in commercetools.
No Collision Handling
This integration implements no duplicate detection, no match fields, and no resolution methods for any collection in this family. Whether a transfer creates or updates a commercetools record is decided solely by whether iPaaS.com already holds an external-ID link for it. If a matching product, variant or inventory entry exists in commercetools but has never been linked through iPaaS.com, this family creates a second record rather than detecting and reusing the existing one. commercetools does treat the product slug and the SKU as unique within a project, so a duplicate product or variant write is normally rejected rather than silently accepted; a duplicate inventory entry is not protected in the same way.
Supported Child Collections
This family is a two-level hierarchy. Three collections hang directly off the product; two more hang off the variant, not off the product.
Parent Collection: Add/Update commercetools Product FROM iPaaS.com
Its three direct child collections:
Add/Update commercetools Product Variant FROM iPaaS.com — writes every variant on the parent Product, carrying the variant SKU and price. Variants are added as instructions beneath the product they belong to.
Add/Update commercetools Product Attribute FROM iPaaS.com — defines on the commercetools product type the attributes the product and its variants need, so that their values have somewhere to be stored.
Add/Update commercetools Product Inventory FROM iPaaS.com — writes stock levels recorded against the Product itself, as part of the product transfer.
Two further collections sit one level deeper, beneath Add/Update commercetools Product Variant FROM iPaaS.com rather than beneath the Product:
Add/Update commercetools Product Variant Inventory FROM iPaaS.com — writes stock levels recorded against an individual variant.
Add/Update commercetools Product Variant Option FROM iPaaS.com — writes the option values that distinguish one variant from another.
None of the five child collections has an independent transfer entry point. Their records move only as part of a parent Product transfer, and every one of them is documented in the Mappings section below.
System Caveats
commercetools Caveats
Product type must exist. commercetools requires every product to reference a product type that already exists in the project. The API reference for product drafts (retrieved 2026-07-20) lists it among the three unconditionally required properties on a new product, alongside name and slug. This integration does not create product types.
Tax category must exist and must match by name. The tax category is resolved by looking up commercetools tax categories and matching the name exactly. When no tax category matches, the lookup does not stop the transfer and does not return nothing — it returns an empty reference that passes the integration's own validation and is sent on to commercetools. See Integration-Specific Caveats below, where this is described as a placeholder that must be replaced.
Slug uniqueness. commercetools treats the product slug as a unique value within a project. Because the slug is derived from the product name, two iPaaS.com Products whose names reduce to the same slug cannot both be created; the second write is rejected.
SKU uniqueness. commercetools treats the SKU as unique within a project, across products and variants alike. A SKU already in use is rejected. The variant key is derived from the variant SKU by removing spaces, so two variants on the same product whose SKUs differ only by spacing produce the same key and the second write is rejected.
Variants live inside the product. commercetools has no standalone variant record — every variant write is an instruction against its parent product. Two variant transfers on the same product cannot proceed simultaneously without one of them failing the record-version check.
Attribute definitions belong to the product type, not the product. Adding a definition affects every product of that type, not only the product whose transfer created it. Attribute names are permanent — renaming an attribute on the iPaaS.com side produces a second definition rather than renaming the existing one — and commercetools will not accept a change of type on a definition that already exists.
Stock keeping unit is the identity of an inventory entry. commercetools identifies an inventory entry by its stock keeping unit together with its supply channel. An item with no stock keeping unit in commercetools cannot carry inventory, and the stock keeping unit cannot be supplied by a mapping — it is always read back from the commercetools product record.
Record versioning. Every update is applied against the target record's current version, which the integration reads immediately before writing. If the same commercetools product, product type or inventory entry is edited elsewhere between that read and the write, the write is rejected as out of date and the transfer fails. Re-running the transfer resolves it.
Platform quotas. The figures below are published at
https://docs.commercetools.com/api/limits(retrieved 2026-07-20). Most commercetools quotas are configurable per project on review; a small number are hard limits that cannot be raised.
Limit | Value | Type |
Variants specifiable on a Product | 100 | Configurable per project |
Product Types per project | 1,000 | Configurable per project |
Embedded Prices per variant | 100 | Configurable per project |
Inventory Supply Channels per store | 100 | Configurable per project |
Attribute Groups per project | 100 | Hard limit — cannot be raised |
Rate limiting. The same page publishes commercetools request limits. There is no claim anywhere that a request declined for a limit is retried or resumed on the subscriber's behalf. Treat a declined request as a failed transfer, not a delayed one: monitor Dashboard / Integration Monitoring / Error Logs, re-run affected records with Manual Sync, and validate expected throughput for large catalogues in a staging environment before relying on it in production.
iPaaS.com Caveats
Field references in dynamic formulas use PascalCase on the iPaaS.com source side, matching the iPaaS.com field names shown in the mapping editor.
The connection test reports success without contacting commercetools. A configuration problem in the connection settings is not caught by the test — it appears at the first transfer instead, as an authorization failure in Dashboard / Integration Monitoring / Error Logs. Validate the connection settings by running a single Manual Sync rather than by relying on the test result. See commercetools Connections and Settings.
Activity is not filed where you would expect it. Activity entries for variant, attribute definition and option value writes are recorded against the Product collection and labelled as product creations or updates. Inventory activity is recorded under Product Category. When tracing any child transfer, look under the parent product for the same time period rather than under the child's own data type, and use Dashboard / Integration Monitoring / Error Logs — where entries can be found by record and timestamp — rather than the activity feed.
Errors on a child collection are reported against the parent. Because the children have no independent entry point, a failure while writing a variant, attribute, option value or inventory record surfaces against the parent Product transfer.
A product transfer can issue a large number of calls to commercetools, because each variant, attribute definition and inventory record is written individually. Products with many variants take proportionally longer to transfer.
The two inventory data types share one field list. The fields offered when mapping Product Inventory are identical to those offered for Product Variant Inventory, so a field meaningful for only one of them still appears when mapping the other. Map only the fields described under Mappings below.
Integration-Specific Caveats
Products arrive unpublished under the shipped mappings. Placeholder value — replace during implementation: the published mapping ships as a Static mapping carrying the example value
unpublish. Left as shipped, every product written by this family is present in commercetools but not visible in the storefront until it is published separately. This is a setting subscribers are expected to decide on during implementation, not a fixed behavior of the integration, and subscribers or their MiSP MUST choose before go-live between publishing on transfer, holding products unpublished for review, or removing the mapping entirely so that each product's existing publication state is left alone.The tax category mapping resolves an example name that will not exist in a subscriber's project. Placeholder value — replace during implementation: the shipped formula looks up the literal tax category name
"Fake". Subscribers or their MiSP MUST repoint it before the first production transfer — at a tax category name that exists in their own commercetools project, at the tax class held on the iPaaS.com Product so that each product resolves its own, or remove the mapping where tax categories are managed in commercetools. Its failure mode is worse than the other placeholders: a no-match returns an empty reference that passes the integration's own validation and is sent on to commercetools with empty identifiers, so the resulting failure does not point back at this mapping and the cause is not obvious from the error text. A product that transfers successfully but carries no tax category will not be taxed correctly at checkout. Check this mapping first when a product write fails for a reason that does not name a field.The attribute input tip ships as example help text that merchandisers will see. Placeholder value — replace during implementation: the inputTip mapping ships as a Static mapping carrying the example value
New English input tip. It is written verbatim onto every attribute definition this integration creates, and it becomes the help text merchandisers see in the commercetools Merchant Center when they edit that attribute. Subscribers or their MiSP MUST replace it before go-live with guidance text appropriate to their attributes, or remove the mapping so that no input tip is written. Because commercetools does not allow an existing definition to be reshaped, replacing the value affects only definitions created after the change — any definition already created with the example text must be corrected directly in commercetools.The product type identifiers in the shipped Lookup Translation belong to another commercetools project. Placeholder value — replace during implementation: see Lookup Translation Tables under Mappings below. They will not resolve in a subscriber's own project and must be replaced before the first transfer.
Prices are affected by two separate and independent defects. See Currency and Price Handling immediately below. A subscriber can be affected by either, or by both.
Inventory depends on Locations, and a Location transfer alone may not be enough. See Inventory Depends on Locations below.
No initialization. Bulk initialization of existing commercetools products, variants or inventory is not supported.
No automatic dependency transfer. Although the steps within a product transfer run in a fixed order, this integration does not transfer one collection's records as a prerequisite for another. Categories in particular are not created on demand — a product referencing a category that has not already been transferred to commercetools will not have that category created for it. Transfer categories before the products that reference them.
Currency and Price Handling
All prices written by this family — the master variant price on the parent collection and the per-variant price on the variant collection alike — are sent to commercetools as a whole number of minor currency units. Two separate defects apply, and they are independent of one another. Fixing or avoiding one does not address the other.
Defect one — the amount assumes a two-decimal currency
The mapped price value is multiplied by 100 to produce the minor-unit amount, and the exponent sent alongside it is always two decimal places. commercetools carries the number of decimal places on every monetary value precisely because it varies by currency; the API reference (retrieved 2026-07-20) makes that exponent a required property of every cent-precision money value. The multiplication is correct for two-decimal currencies such as the US dollar, the euro and the pound sterling, and wrong for a zero-decimal currency such as the Japanese yen or a three-decimal currency such as the Bahraini dinar, where the resulting amount is off by a factor of 100 or 10 respectively. Any fractional remainder beyond two decimal places is discarded rather than rounded.
Defect two — the currency label is always United States dollars
Independently of the amount, every price this family writes carries the currency code USD and a United States price country, unconditionally and regardless of the currency the catalogue is actually priced in. A subscriber selling in euros or pounds therefore has every price written into commercetools labelled as USD in a US price scope even where the numeric amount is correct, because the euro and the pound are themselves two-decimal currencies. This affects every subscriber pricing outside the United States and is not corrected by pricing in a two-decimal currency.
Neither defect is fixed by changing a mapping's source value. Subscribers whose catalogue is priced in any currency other than the United States dollar must validate the amount, the currency label and the price scope in a staging environment before relying on this in production.
A single price is written per variant. commercetools price scopes such as per-channel or per-customer-group pricing are not used.
Inventory Depends on Locations
Neither inventory collection can write stock into commercetools without a supply channel, and the supply channel comes from an iPaaS.com Location that has already been transferred.
The Location mapping on both inventory collections does not pass the iPaaS.com location value through unchanged — it converts the iPaaS.com Location into the matching commercetools supply channel by looking up the link iPaaS.com holds for that Location. The supply channel must therefore already exist and already be linked. When no link can be found, the transfer stops with an error rather than writing the entry without a supply channel. Transfer Locations before the inventory that references them.
Transferring the Location is necessary but may not be sufficient. commercetools marks a channel as usable for tracking inventory by giving it an inventory-supply role, and the Location transfer does not set that role. Before relying on inventory transfers in production, subscribers or their MiSP should open each channel that will hold stock in commercetools, confirm it carries the inventory-supply role, and add the role there if it is missing.
An inventory entry written to commercetools without a supply channel can never be updated through this integration. Every later change to such an entry fails, and the entry can only be corrected in commercetools directly. This is why the Location mapping must be treated as required and must resolve for every inventory record, even though commercetools itself documents the supply channel as optional.
Moving stock between channels is a separate concern. The instruction that sets an entry's supply channel is not sent in the same form when an entry is created as when an existing entry is changed, so a channel move may be rejected even where creating an entry against that channel succeeds. Validate channel moves specifically in a staging environment.
The behavior of the Location transfer itself, including how commercetools supply channels are created from iPaaS.com Locations, is described in the Location mapping documentation rather than repeated here.
Setup Requirements
iPaaS.com Configuration
Complete and valid commercetools connection settings. Because the connection test always reports success, confirm them with a single Manual Sync. See commercetools Connections and Settings and commercetools Installation Instructions.
Enable the outbound subscriptions listed under Mapping Collection Status for each collection whose records should transfer without manual intervention. Attribute definitions and option values have no subscriptions of their own and travel with the product.
Replace all four shipped placeholder values before go-live: the published Static value, the taxCategory formula's
"Fake"lookup name, the inputTip Static value, and the product-type identifiers in the iPaaS Product Tracking To CommerceTools Type Id lookup translation.Add a lookup translation row for every iPaaS.com tracking method value the catalogue uses beyond the two shipped rows.
Consider adding a MinQuantity mapping to both inventory collections. Neither ships with one, and without it a newly created inventory entry publishes an available quantity of zero and reads as out of stock until a later change corrects it.
Ensure each iPaaS.com Product intended for transfer carries a name, a SKU and at least one variant, and that each variant carries a SKU and at least one option value.
Run Add commercetools Location FROM iPaaS.com for every Location referenced by inventory, before transferring that inventory.
Transfer categories to commercetools before the products that reference them.
commercetools Configuration
A commercetools project with API client credentials that permit reading and writing products, product types, channels and inventory. The endpoints used by this family are listed in commercetools API Endpoints.
The product types this catalogue uses must already exist. This integration does not create them.
The tax categories this catalogue uses must already exist, matched by exact name.
Any attribute needing settings other than the fixed set this integration applies — a type other than a keyed option list, a required attribute, a cross-variant constraint, a single-line presentation or a non-searchable attribute — must be defined directly in commercetools before the first product transfer, so that the attribute collection finds it already defined and adds nothing.
Every channel that will hold stock must carry the inventory-supply role.
Integration Flow
A Product transfer is dispatched from iPaaS.com, either automatically from an enabled Outbound Data Flows subscription or on demand from Manual Sync using the numeric iPaaS.com Product ID.
The integration retrieves the full iPaaS.com Product record, including its variants, their option values, and inventory at both product and variant level.
The product's variant collection is counted. A product carrying more than 100 variants is stopped here with an error and nothing is written — see the error condition under Add/Update commercetools Product FROM iPaaS.com below.
The integration checks whether the iPaaS.com Product already carries a commercetools external-ID link. The presence or absence of that link — not the triggering event — decides whether the transfer is an Add or an Update.
Add (no link stored): the product is created from a complete draft carrying the mapped product fields, its category assignments, its tax category, and its first variant as the master variant with that variant's price and attribute values. Fields left unmapped are simply omitted and commercetools applies its own default, so the Add path carries no overwrite risk.
Update (link stored): the integration first reads the current commercetools product to obtain its record version, then submits a set of change instructions against that version. The instructions always include description_enUS and name_en, whether or not they are mapped. Category assignment, tax category, publication state and attribute instructions are added only when the corresponding value is present.
Attribute definitions before variants: where the product or one of its variants carries an attribute the commercetools product type does not yet define, the integration adds the missing attribute definition — and any missing option value on an existing definition — before it adds or updates the variants that use it. An existing definition is never reshaped; a missing option value is added to it instead.
Variants: each variant is written as an instruction against the parent product, carrying the variant SKU, its key derived from the SKU with spaces removed, its price and its option values. Because the first variant of a new product was already written as the master variant in step 5, this step adds the remainder.
Option values: each variant's option values ride on the variant instruction on the Add path, and are sent as separate set-attribute instructions on the Update path. A new variant carrying no option values fails, and takes the parent product transfer down with it.
Inventory: product-level and variant-level stock are written last. For each entry the integration reads the relevant product back from commercetools to take the item's stock keeping unit from the product record, resolves the supply channel from the mapped Location, and creates the entry. Where an entry already exists, only the values that actually differ are sent.
iPaaS.com records the returned commercetools identifiers against the corresponding iPaaS.com records — product, variant and inventory entry — so that the next transfer routes to an update rather than a duplicate create.
Any failure is reported in Dashboard / Integration Monitoring / Error Logs against the parent Product transfer, including failures raised while writing a variant, an attribute definition, an option value or an inventory entry.
Mappings
Add/Update commercetools Product FROM iPaaS.com
iPaaS.com data type: Product
Description: Writes an iPaaS.com Product record into commercetools as a product record, creating it on the first transfer and updating it on every transfer thereafter. This collection sits at the head of the family and its transfer carries every child collection's records with it. It has no mapping filter, so every dispatched Product is processed — but it does carry an error condition, described immediately below.
Error Condition
if (Variants != null){
if (Variants.count > 100)
throw new exception("Commercetools does not allow more than 100 variants");
}
return false;Error Condition Description: Before the product is written, its variant collection is examined. Where the product carries a variant collection at all, the number of variants in it is counted. A product with more than 100 variants is stopped, and the transfer fails with the message Commercetools does not allow more than 100 variants. Products with 100 variants or fewer, and products carrying no variant collection at all, pass this check and continue to be written normally. The message appears in Dashboard / Integration Monitoring / Error Logs, where subscribers can search for that text to identify affected products.
The 100-variant figure is a real, documented commercetools platform limit. The commercetools limits documentation at https://docs.commercetools.com/api/limits (retrieved 2026-07-20) states: "A maximum number of 100 variants can be specified on a Product."
Important: the same page also states that this limit can be increased per project after commercetools reviews the performance impact. The integration's guard, however, is a fixed 100 and does not read the project's configured limit. A subscriber whose commercetools project has had the variant limit raised is therefore still stopped at 100 by this integration, and the message they see — which attributes the stop to commercetools — will not be accurate for their project. Where a catalogue genuinely needs more than 100 variants on a single product, raising the limit in commercetools alone is not sufficient.
Mapping Type | Source Field (iPaaS.com) | Destination Field (commercetools) | Description |
Field | Name | name_en | Required. Sets the English product name. commercetools lists name as one of three unconditionally required properties on a new product (product draft API reference, retrieved 2026-07-20), and a transfer with no name is rejected. Doubly important because the slug is derived from this same name. On update an instruction to change the name is always sent whether or not this mapping is present, so an empty source value clears the name rather than leaving it in place. |
Dynamic Formula | Slug derived from the product name (see formula below) | slug_en | Required. commercetools lists slug among the three unconditionally required properties on a new product. The formula strips every character that is not a letter, digit, hyphen or underscore from the product name and returns the result with a leading forward slash. Spaces and punctuation are removed rather than converted to hyphens, so |
Lookup | Lookup Translation: iPaaS Product Tracking To CommerceTools Type Id | productType_id | Required. commercetools lists productType among the three unconditionally required properties on a new product and will not accept a product referencing a product type that does not exist. The translation reads the iPaaS.com TrackingMethod value and returns a commercetools product type identifier. Placeholder value — replace during implementation: the shipped identifiers belong to another project. See the Lookup Translation Tables below. |
Field | Description | description_enUS | Recommended, but treat as required in practice. Sets the English product description. commercetools does not require a description on a product draft. However, this collection sends an instruction to set the description on every update whether or not this mapping is present, so removing it does not leave the commercetools value alone — it clears it. When the iPaaS.com Product has no description recorded, the commercetools description is set to empty. Protect it with a |
Field | Sku | sku | Recommended. Carries the product SKU. commercetools stores the SKU on the variant rather than on the product, so this value identifies the product's master variant. commercetools does not require it, but products intended to carry inventory or to be matched by downstream systems should always supply one — an item with no SKU in commercetools cannot carry inventory. commercetools treats the SKU as unique within a project, so a SKU already in use on another product or variant causes the write to be rejected. |
Dynamic Formula | Price in minor currency units (see formula below) | price | Recommended. Supplies the price for the product's master variant, converting a decimal price such as 19.99 into 1999 minor currency units. commercetools does not require a price on a product draft, but a product transferred with no price value is written with a price of zero rather than with no price at all, so an unmapped or empty price silently produces a free product. Two independent defects affect this mapping — the amount assumes a two-decimal currency, and separately every price is labelled USD in a US price scope. See Currency and Price Handling above. |
Dynamic Formula |
| categories | Optional. Resolves each category on the iPaaS.com Product to the identifier of the matching commercetools category, using the external-ID link recorded when that category was transferred. commercetools does not require categories on a new product. On update the category instruction is sent only when a value is present, so leaving this mapping empty leaves existing commercetools category assignments alone rather than clearing them. A category not already transferred to commercetools is not created on demand — transfer categories first. The formula name is shown exactly as it appears in the mapping-formula picker; it contains a spelling error that cannot be corrected without breaking this mapping. |
Dynamic Formula |
| taxCategory | Optional as far as commercetools is concerned; on update the instruction is sent only when a value is present. Looks up the tax categories defined in the commercetools project and matches one by its exact name. Placeholder value — replace during implementation: the shipped formula looks up the literal name |
Static |
| published | Optional — the instruction is sent only when a value is present. Controls whether the product is published to the commercetools storefront when written; commercetools accepts |
The slug_en formula referenced above, reproduced verbatim:
var result = Name;
result.Replace(">","_");
result.Replace(" ","_");
result.Replace("___","_");
result.Replace("__","_");
Regex rgx = new Regex("[^a-zA-Z0-9-_]");
return "/" + rgx.Replace(result, "");The price formula referenced above, reproduced verbatim:
double originalPrice = DefaultPrice; int priceCents = (int)(originalPrice * 100); return priceCents;
Both formulas run automatically and need no subscriber configuration; their text is visible and editable in the iPaaS.com mapping editor.
Lookup Translation Tables
Lookup Translation: iPaaS Product Tracking To CommerceTools Type Id — reads the TrackingMethod field on the iPaaS.com Product and returns the commercetools product type identifier the product is created against. Two rows ship by default.
Source Value | Destination Value | Notes |
Product |
| For products tracked at the product level. |
Variant |
| For products tracked at the variant level. |
Placeholder value — replace during implementation: unlike a lookup whose destination values are platform constants, both identifiers above are the product types of the specific commercetools project this integration was configured against. Product type identifiers are specific to a single commercetools project and will not resolve in any other. Subscribers or their MiSP MUST replace both values with the identifiers of the corresponding product types in their own commercetools project before the first transfer. A product type identifier that does not exist in the destination project causes the product write to be rejected, and the error appears in Dashboard / Integration Monitoring / Error Logs.
Where the catalogue uses more than these two product types, add a translation row for each additional tracking method value. A tracking method with no matching row leaves the product type unset and the write is rejected. This integration does not create product types — they must already exist in commercetools.
Add/Update commercetools Product Variant FROM iPaaS.com
iPaaS.com data type: Product Variant
Description: Writes every iPaaS.com Product Variant on the parent Product into commercetools as a variant beneath that product, so that each sellable combination — each size, colour or configuration with its own SKU and price — exists in commercetools as a distinct, individually purchasable variant. Variants are written as change instructions against the parent product rather than as records of their own. This collection has no mapping filter, so every variant on a dispatched Product is processed. It is itself the parent of two further collections.
Mapping Type | Source Field (iPaaS.com) | Destination Field (commercetools) | Description |
Dynamic Formula |
| ProductId | Required. Resolves the commercetools product this variant belongs to, by reading the external-ID link recorded against the parent iPaaS.com Product when it was transferred. commercetools has no standalone variant record — every variant is written as an instruction against its parent product — so without this identifier there is nothing to write the variant against and the transfer fails with a message stating that a product identifier is required. In practice this means the parent Product must already have been transferred to commercetools. Transferring the parent through Manual Sync writes its variants in the correct order automatically. Subscribers should not change this mapping. |
Field | Sku | sku | Required in practice. Sets the variant SKU. The commercetools variant draft reference (retrieved 2026-07-20) does not mark the SKU required at the schema level, but this integration uses it to build both the variant SKU and the variant key, and a variant transferred without one will fail. The key is derived from the SKU by removing spaces, so two variants on the same product whose SKUs differ only by spacing produce the same key and the second write is rejected. commercetools also treats the SKU as unique within a project, and it must differ from the parent product's own SKU, which identifies the master variant. |
Dynamic Formula | Price in minor currency units (see formula below) | Price | Recommended. Supplies this variant's price, converting a decimal price such as 19.99 into 1999 minor currency units. commercetools does not require a price on a variant, but a variant transferred with no price value is written with a price of zero rather than with no price at all, so an unmapped or empty price silently produces a free variant. The same two independent currency defects that affect the product price apply here — see Currency and Price Handling above. A single price is written per variant. |
The Price formula referenced above, reproduced verbatim:
double originalPrice = DefaultPrice; int priceCents = (int)(originalPrice * 100); return priceCents;
Add/Update commercetools Product Attribute FROM iPaaS.com
iPaaS.com data type: Product Option
Description: Defines on the commercetools product type the attributes a transferred product and its variants need, so that their attribute values have somewhere to be stored. This collection writes attribute definitions, not attribute values — the values travel with the product and its variants. All six of its mappings are fixed values rather than fields drawn from the iPaaS.com record, and they govern the shape of every attribute definition this integration creates. The attribute's own name and label are taken from the attribute record itself and are not mapped here. This collection has no mapping filter, and no outbound scope — its records move only as part of a parent Product transfer.
Mapping Type | Source Field (iPaaS.com) | Destination Field (commercetools) | Description |
Static |
| typeName | Required. commercetools lists the attribute type among the four properties required on a new attribute definition (attribute definition draft reference, retrieved 2026-07-20). |
Static |
| isRequired | Required. commercetools lists this among the four properties required on a new definition. |
Static |
| attributeConstraint | Optional — commercetools does not list the attribute constraint among the required properties on a new definition. Sets whether commercetools enforces a relationship between this attribute's values across a product's variants. commercetools documents four accepted values: None (no constraint), Unique (a different value on every variant), CombinationUnique (the set of so-constrained attributes forms a distinct combination on each variant) and SameForAll (every variant carries the same value). A designed constant, not a placeholder; |
Static |
| inputHint | Optional — a presentation hint only; it does not constrain what may be stored. commercetools documents two accepted values: SingleLine and MultiLine. A designed constant, not a placeholder; |
Static |
| isSearchable | Optional — commercetools does not list it among the required properties on a new definition. Makes every attribute this collection defines available to storefront search and faceted navigation. A designed constant, not a placeholder. Making an attribute searchable adds it to the project's search index, so subscribers defining a large number of attributes through this integration should set it to |
Static |
| inputTip | Optional — removing this mapping produces definitions with no help text at all. Placeholder value — replace during implementation: this example text is written verbatim onto every attribute definition this integration creates, and it becomes the help text merchandisers see in the commercetools Merchant Center when they edit that attribute. Subscribers or their MiSP MUST replace it before go-live with guidance text appropriate to their attributes, or remove the mapping. Replacing it affects only definitions created afterwards; definitions already carrying the example text must be corrected directly in commercetools. |
Definitions are added, never removed or reshaped
Where a definition already exists under the same name, this collection adds any missing option value to it rather than redefining it. Changing the fixed values above therefore affects only definitions created after the change. An attribute definition whose type or behavior settings need to change must be changed directly in commercetools.
Definitions are shared across the product type
An attribute definition belongs to the commercetools product type, not to an individual product, so adding one affects every product of that type. Review the attribute set on each product type after the first product transfer rather than assuming the change is scoped to one product.
Add/Update commercetools Product Inventory FROM iPaaS.com
iPaaS.com data type: Product Inventory
Description: Writes the stock level held against an iPaaS.com Product into commercetools as an inventory entry, as part of the product transfer, so that a product arriving in commercetools arrives with stock on it rather than requiring a second, separate step. The entry is not written from the mapped values alone — the integration reads the product back from commercetools to take the item's stock keeping unit from the product record, because there is no mapping for it and none should be added. On a change to an existing entry, only the values that actually differ are sent. This collection has no mapping filter, so every inventory record on a dispatched Product transfer is processed.
Mapping Type | Source Field (iPaaS.com) | Destination Field (commercetools) | Description |
Dynamic Formula |
| ProductId | Required. Supplies the commercetools product the inventory belongs to, by reading the link iPaaS.com holds between the parent iPaaS.com Product and its commercetools product record. The integration uses it to read the product back from commercetools so it can take the item's stock keeping unit from that record. If it resolves to nothing, the transfer stops with an error stating that a product identifier is required and no inventory entry is written. No configuration is needed provided the parent product has already been transferred; because this collection runs inside that transfer, the link is normally in place by the time the inventory record is processed. An iPaaS.com Product never published to commercetools cannot carry inventory. |
Field | QtyAvailable | Quantity | Required in practice. Sets the stock on hand recorded against the commercetools inventory entry. The commercetools inventory entry documentation (retrieved 2026-07-20) lists the stock keeping unit and the stock quantity as the only required values on a new entry, and this mapping supplies the quantity. If the mapping is removed, a stock level of zero is written rather than the field being left alone. Where the entry already exists, the quantity is sent only if it differs from the stored value, so a record whose quantity has not changed produces a write that changes nothing. |
Dynamic Formula |
| Location | Treat as required. Sets the commercetools supply channel the stock sits in, converting the iPaaS.com Location into the matching supply channel by looking up the link iPaaS.com holds for that Location — it does not pass the value through unchanged. commercetools documents the supply channel as optional on an inventory entry, but an entry written without one can never be updated through this integration afterwards and can only be corrected in commercetools directly. The iPaaS.com Location must already have been transferred by Add commercetools Location FROM iPaaS.com; where no match exists the conversion raises an error and the transfer stops rather than writing the entry without a channel. See Inventory Depends on Locations above. |
MinQuantity is not mapped, and should be. When the integration creates a new inventory entry it sends an explicit available quantity taken from the MinQuantity value; with no mapping in place it sends zero, and the new entry reads as out of stock in commercetools until a later change corrects it. Changes to an entry that already exists do not send available quantity at all. Adding a MinQuantity mapping is strongly recommended on any collection that can create inventory entries. Note also that commercetools reports an item's available quantity as its stock on hand less any reservations, so the two values will not always match.
Add/Update commercetools Product Variant Inventory FROM iPaaS.com
iPaaS.com data type: Product Variant Inventory
Description: Writes the stock level held against an iPaaS.com Product Variant into commercetools as an inventory entry, as part of the variant transfer. It is a child of Add/Update commercetools Product Variant FROM iPaaS.com, not of the Product. As with product-level inventory, the variant's stock keeping unit is read back from the commercetools product record rather than supplied by a mapping, and a change to an existing entry sends only the values that actually differ. This collection has no mapping filter, so every inventory record on a dispatched Product Variant transfer is processed.
Mapping Type | Source Field (iPaaS.com) | Destination Field (commercetools) | Description |
Dynamic Formula | Parent product resolved from the variant (see formula below) | ProductId | Required. Supplies the commercetools product that owns the variant the inventory belongs to. The formula reads the variant identifier out of the leading portion of the inventory record's own composite identifier, resolves that variant back to the iPaaS.com Product it belongs to, and returns the commercetools product identifier from that Product's external-ID link. The integration uses it to read the product back so it can locate the variant and take its stock keeping unit. If it resolves to nothing — because the identifier carries no variant portion, because the variant resolves to no Product, or because that Product has never been published — the transfer stops with an error stating that a product identifier is required. |
Field | QtyAvailable | Quantity | Required in practice. Sets the stock on hand recorded against the commercetools inventory entry for this variant. The commercetools inventory entry documentation (retrieved 2026-07-20) lists the stock keeping unit and the stock quantity as the only required values on a new entry. If the mapping is removed, a stock level of zero is written rather than the field being left alone. Where the entry already exists the quantity is sent only if it differs from the stored value. |
Dynamic Formula |
| Location | Treat as required. Sets the commercetools supply channel the variant's stock sits in, converting the iPaaS.com Location into the matching supply channel by looking up the link iPaaS.com holds for that Location. commercetools documents the supply channel as optional, but an entry written without one can never be updated through this integration afterwards. The iPaaS.com Location must already have been transferred by Add commercetools Location FROM iPaaS.com; where no match exists the transfer stops rather than writing the entry without a channel. See Inventory Depends on Locations above. |
Dynamic Formula |
| ParentId | Recommended — leave it mapped. Supplies the commercetools variant this stock belongs to, by reading the link iPaaS.com holds between the parent iPaaS.com Product Variant and its commercetools variant record. It records which variant the inventory record was raised against and keeps the transferred record associated with the right variant. No configuration is needed provided the parent variant has already been transferred; where the parent variant has never been published to commercetools this resolves to nothing. |
The ProductId formula referenced above, reproduced verbatim:
int parentPos = Id.IndexOf('|');
int VariantId = Convert.ToInt32(Id.Substring(0, parentPos));
var parentId = await ParentIdFromVariantId(VariantId);
return await GetExternalIdAsync(parentId, "Product", SpaceportSystemId);MinQuantity is not mapped here either, with the same consequence described under the product inventory collection above: a newly created entry publishes an available quantity of zero and reads as out of stock until a later change corrects it. Adding the mapping is strongly recommended.
Add/Update commercetools Product Variant Option FROM iPaaS.com
iPaaS.com data type: Product Variant Option
Description: Writes the option values that distinguish one commercetools variant from another — the size, colour or configuration a shopper selects — onto the variant as commercetools variant attributes. It is a child of Add/Update commercetools Product Variant FROM iPaaS.com, not of the Product. It creates no record of its own in commercetools: option values exist only as part of the variant they belong to, so this collection's output always travels with a parent variant write. It is distinct from Add/Update commercetools Product Attribute FROM iPaaS.com, which defines on the product type which attributes may exist; both are normally needed, because a value can only be written where a matching definition already exists. This collection has no mapping filter, and no outbound scope.
Mapping Type | Source Field (iPaaS.com) | Destination Field (commercetools) | Description |
Field | OptionName | name | Required. Supplies the name of the commercetools variant attribute the option value is stored against — the name of the size or colour option rather than the particular size or colour. The commercetools variant attribute reference (retrieved 2026-07-20) marks the name as a required property of every attribute. It must match an attribute already defined on the parent product's product type or commercetools rejects the write; missing definitions are added during the parent Product transfer. This name is also the only thing identifying the option value within the variant — there is no separate link — so renaming an option on the iPaaS.com side produces a second attribute on the commercetools variant rather than renaming the existing one, and the original value stays in place. Settle option names before the first transfer. |
Field | Value | key | Required. Supplies the option value itself — the text that distinguishes this variant from its siblings. The commercetools variant attribute reference (retrieved 2026-07-20) marks the value as a required property of every attribute. On a variant being added for the first time this value is written as both the option key commercetools stores and the option label a user interface displays, so the same text serves both purposes; a stored code that differs from its displayed label cannot be expressed through this mapping and must be maintained directly in commercetools. On an existing variant the value is applied to the named attribute in place. A new variant transferred with an empty option set fails with a message stating that variant options are required, and the parent product transfer fails with it — so leaving this mapping unset produces a failed transfer, not an option with no value. |
The value must also be acceptable to the attribute's definition on the product type, which commercetools will not allow to change type once created. Validate option values against the product type definitions in a staging environment before relying on them in production.
Error Handling
Failures for all six collections are reported against the parent Product transfer in Dashboard / Integration Monitoring / Error Logs, because none of the children has an independent entry point. A fuller catalog is maintained in commercetools Error Messages.
"Commercetools does not allow more than 100 variants" — the Product carries more than 100 variants and is stopped before anything is written. Resolution: reduce the variant count on the iPaaS.com Product, or split the catalogue item across more than one product. Note that raising the variant limit on the commercetools project does not raise this integration's threshold, which is fixed at 100.
A product transferred with no name is rejected. commercetools requires a name on every product, and the slug is derived from it, so a missing name fails both required fields at once. Resolution: populate the name on the iPaaS.com Product, confirm the name_en mapping is present, and re-run.
A product whose slug is already in use in commercetools is rejected. Two Products whose names reduce to the same slug collide. Resolution: differentiate the product names, or replace the slug formula with one that produces distinct values.
A product whose product type identifier does not exist in the commercetools project is rejected. Resolution: replace the destination values in the iPaaS Product Tracking To CommerceTools Type Id lookup translation with product type identifiers from your own project, and add a row for any tracking method value not yet covered.
A product write fails for a reason that does not name a field. Check the taxCategory mapping first. A no-match on the tax category name returns an empty reference that passes validation and is sent on to commercetools with empty identifiers, so the error text does not point back at the mapping that caused it. Resolution: repoint the formula at a tax category name that exists in your project, or remove the mapping.
A SKU already in use in commercetools is rejected. commercetools treats the SKU as unique within a project, across products and variants alike. Resolution: correct the duplicate SKU in iPaaS.com. Check also that no two variant SKUs on the same product become identical once spaces are removed, since the variant key is derived that way.
A variant transfer fails with a message stating that a product identifier is required. The parent Product has never been transferred to commercetools, or its external-ID link has been cleared. Resolution: transfer the parent Product first — running Manual Sync on the parent writes its variants in the correct order automatically.
A new variant transferred with no option values fails, and takes the parent product transfer down with it. Resolution: ensure every iPaaS.com Product Variant carries at least one option value before transferring.
An option value whose attribute name is not defined on the product type is rejected. Resolution: transfer the variant as part of its parent Product so that missing definitions are created first, or define the attribute directly in commercetools.
An inventory transfer stops because the supply location cannot be resolved. The iPaaS.com Location has not been transferred to commercetools, so no linked supply channel exists. Resolution: run Add commercetools Location FROM iPaaS.com for that Location, confirm the resulting channel carries the inventory-supply role, and re-run the product transfer.
Every update to a particular inventory entry fails. The entry was written to commercetools without a supply channel and cannot be updated through this integration afterwards. Resolution: correct the entry directly in commercetools, and ensure the Location mapping resolves for every inventory record going forward.
An update rejected because the record version is out of date. The commercetools product, product type or inventory entry was edited elsewhere between the version read and the write. Resolution: re-run the transfer with Manual Sync; the integration reads the current version again.
An authorization failure on the first transfer after setup. The connection test reports success without contacting commercetools, so credential problems surface here rather than at test time. Resolution: correct the connection settings per commercetools Connections and Settings and re-run a single Manual Sync.
A delete attempt fails with the message "The method or operation is not implemented." Delete is not implemented for any collection in this family. Resolution: none through the integration — remove the record directly in commercetools.
A request declined for a commercetools request limit or project quota. Treat it as a failed transfer, not a delayed one; there is no claim of automatic retry or resumption. Resolution: re-run affected records with Manual Sync and reduce concurrent load.
Validation Rules
Name present on every Product. Enforced by commercetools; a transfer without it is rejected, and the slug derived from it fails with it.
Slug unique within the commercetools project. Enforced by commercetools on create.
Product type resolvable and existing in the project. Enforced by the lookup translation followed by commercetools validation.
No more than 100 variants on a Product. Enforced by the integration itself as a fixed threshold, independently of the project's configured commercetools limit.
At least one variant on every Product. Enforced by the integration, which uses the first variant as the commercetools master variant when creating a product.
At least one option value on every new variant. Enforced by the integration; a new variant with an empty option set fails and takes the parent product transfer with it.
SKU unique within the commercetools project, and unique across variants on the same product once spaces are removed. Enforced by commercetools and by the variant key derivation respectively.
Attribute name defined on the product type before a value is written. Enforced by commercetools; missing definitions are created earlier in the same transfer.
Supply channel resolvable on every inventory record. Enforced by the integration; an unresolvable Location stops the transfer.
Record version current at write time. Enforced by commercetools optimistic concurrency on every update.
Testing & Validation
Test Scenarios
New product create. Create a Product in iPaaS.com with a name, a SKU, a price, a tracking method covered by the lookup translation, and one variant carrying a SKU and one option value. Run Manual Sync with its numeric iPaaS.com Product ID. Expected outcome: a new commercetools product appears with the mapped fields, its master variant, its attribute definition and its option value, and iPaaS.com records a commercetools GUID as the external ID on the Product and on the variant.
Publication state. Immediately after that first transfer, look for the product in the storefront. Expected outcome under the shipped mappings: it is present in commercetools but not visible in the storefront. Confirm this matches the behavior you intend before changing or removing the published mapping.
Existing product update. Change the product name and re-run Manual Sync. Expected outcome: the existing commercetools product is updated in place — no second product is created — and the slug changes with the name.
Unmapped-field overwrite. In a staging environment only, remove the description_enUS mapping, set a description directly on the commercetools product, and re-run the transfer. Expected outcome: the commercetools description is cleared. Then add a Dynamic Formula mapping of
DestinationValue.description_enUSto description_enUS and re-run. Expected outcome: the commercetools value is preserved. Restore the original mapping afterwards.Required-field validation. Clear the name on a test Product and attempt a transfer. Expected outcome: the transfer fails with a rejection recorded in Dashboard / Integration Monitoring / Error Logs.
Variant cap. Attempt a transfer of a Product carrying more than 100 variants. Expected outcome: the transfer fails with Commercetools does not allow more than 100 variants and nothing is written. Repeat this even if your commercetools project's variant limit has been raised — the integration's threshold is fixed.
Parent-before-child ordering. Confirm that transferring the parent Product writes its variants, attribute definitions, option values and inventory in one sequence, and that a variant cannot be transferred before its parent product exists.
Placeholder replacement — product type. Replace both destination values in the iPaaS Product Tracking To CommerceTools Type Id translation with product type identifiers from your own commercetools project, then transfer a product of each tracking method. Expected outcome: both succeed. Before replacement, expect a rejection.
Placeholder replacement — tax category. Repoint the taxCategory formula at a tax category that exists in your project, transfer a product, and confirm in commercetools that the product carries the intended tax category. Expected outcome: the tax category is set. Note that a product transferred with the unreplaced value may appear to succeed while carrying no tax category — check the product record, not only the transfer result.
Placeholder replacement — input tip. Replace the inputTip value, transfer a product carrying a previously unseen attribute, and open that attribute definition in the commercetools Merchant Center. Expected outcome: the new help text is shown. Definitions created before the change still carry the example text and must be corrected in commercetools.
Currency validation. If the catalogue is priced in any currency other than the United States dollar, transfer a product and inspect the resulting commercetools price. Expected outcome to verify explicitly: the numeric amount, the currency code, and the price country. Amounts are correct for two-decimal currencies; the currency code and country are USD and US regardless.
Inventory with Locations. Transfer a Location, confirm the resulting commercetools channel carries the inventory-supply role, then transfer a product carrying stock at that Location. Expected outcome: the inventory entry is created with the right supply channel and quantity. Then attempt an inventory transfer referencing an untransferred Location. Expected outcome: the transfer stops with an error.
Available quantity. After creating a new inventory entry with no MinQuantity mapping, check the item in commercetools. Expected outcome: it reads as out of stock despite a non-zero stock on hand. Add a MinQuantity mapping and re-test.
Duplicate inventory paths. With both a family inventory collection and its standalone counterpart enabled, make a single stock change in iPaaS.com. Expected outcome: the change is processed twice. Decide which collection owns ongoing stock updates and configure accordingly.
Automatic transfer. Enable the Outbound Data Flows subscriptions listed under Mapping Collection Status, change a Product in the upstream system of record, and confirm the transfer runs without a Manual Sync. Confirm separately that attribute definitions and option values still travel with the product, since neither has a subscription of its own.
Validation Checklist
The numeric iPaaS.com Product ID is accepted on the Manual Sync page and the transfer completes.
A commercetools GUID is recorded as the external ID on the iPaaS.com Product, on each variant, and on each inventory record.
Both description_enUS and name_en are mapped, or are protected by a
DestinationValueformula.All four placeholder values have been resolved: the published Static value, the taxCategory lookup name, the inputTip Static value, and both product type identifiers in the lookup translation.
The lookup translation holds a row for every tracking method value present in the source data.
Every Product intended for transfer carries a name, a SKU and at least one variant; every variant carries a SKU and at least one option value.
Variant SKUs remain distinct once spaces are removed.
Categories have been transferred to commercetools before the products that reference them.
Locations have been transferred, and every channel that will hold stock carries the inventory-supply role in commercetools.
The Location mapping resolves for every inventory record on both inventory collections.
A MinQuantity mapping has been added to both inventory collections, or the out-of-stock consequence has been accepted deliberately.
Ownership of ongoing stock updates has been decided between each family inventory collection and its standalone counterpart.
Prices have been verified for amount, currency code and price country if the catalogue is priced outside the United States dollar.
The outbound subscriptions are enabled under Outbound Data Flows if automatic transfer is expected.
A repeat transfer of the same Product updates the existing commercetools product rather than creating a second one.
Error Logs are clear after a full test pass.
Additional Notes
The following are not performed by this family of collections:
Delete of any kind — products, variants, attribute definitions, option values and inventory entries are never removed from commercetools by this integration, in either direction.
Inbound transfer. commercetools products, variants, attributes, option values and stock levels are not brought into iPaaS.com. This family writes in one direction only.
Product type creation. Product types must already exist in commercetools.
Category creation as part of a product transfer. Categories are transferred by their own collection and are not created on demand.
Reshaping existing attribute definitions. An existing definition's type, constraint, presentation or searchability settings are not changed by a subsequent transfer.
Separate option codes and display labels. A single mapped value supplies both.
Localised names, labels and tips beyond English. Product names, descriptions, slugs, attribute labels, input tips and option labels are written in English only.
Product images, assets, search keywords and metadata fields. These commercetools product properties are not written.
Multiple prices per variant. A single price is written per variant; commercetools price scopes such as per-channel or per-customer-group pricing are not used.
Reservations and stock levels beyond stock on hand. Restock lead time, expected delivery, cart quantity limits and reservation handling are not written.
Reading stock back from commercetools. There is no inbound flow that brings commercetools stock levels into iPaaS.com.
Custom fields. Neither product, variant nor inventory custom fields are written.
Collision handling and duplicate detection. Not implemented for any collection in this integration.
Initialization. Bulk initialization of existing commercetools products, variants or inventory is not supported.
Further constraints that apply across the whole integration are described in commercetools Integration Known Limitations, and the endpoints used by these collections are listed in commercetools API Endpoints. For assistance, contact iPaaS.com Support at support@ipaas.com.