Summary
Zoho Commerce products can be created and updated from iPaaS.com Product records through automatic outbound triggers or on-demand Manual Sync. Each transfer sends the product's core catalog detail — name, both storefront descriptions, unit of measure, product-level SKU, list and selling prices, storefront URL, storefront visibility and category assignment — together with the names and types of the configurable attributes the product is sold in, and it carries the product's variants in the same operation, so one transfer establishes the product and the stocking units beneath it. Product data moves in one direction only, from iPaaS.com to Zoho Commerce.
ID Format
Manual Sync ID Format
On the iPaaS.com Manual Sync page, enter the iPaaS.com Product record ID — the identifier of the Product record in iPaaS.com that you want to transfer. It is not the Zoho Commerce product ID. Example: 1234.
Manual Sync transfers the product together with its variants. Neither variant collection has an independent Manual Sync entry point of its own: to push a variant on demand, run a Manual Sync of its parent product.
External ID Format
After a product transfers successfully, iPaaS.com records the Zoho Commerce product ID as the external ID on a dedicated external-ID record for that product. Example: 4619534000000093333. Every later transfer of the same product uses this link to update the existing Zoho Commerce product instead of creating a new one.
Each variant saves its own external-ID link in the same way, holding the Zoho Commerce variant ID. Example: 4159044000000097115. If an external-ID link is cleared, the next transfer creates a second Zoho Commerce record rather than updating the existing one.
Deleted Record Support
Outbound delete is not supported for any of the three collections in this family. Deleting a Product or a Product Variant in iPaaS.com does not delete the corresponding product or variant in Zoho Commerce, delete mappings are not included in the default templates, and deletions do not propagate. Products and variants that are no longer wanted must be removed in Zoho Commerce directly.
Custom Field Support
Zoho Commerce custom fields are supported for products, with one structural requirement that determines where everything is configured: Zoho Commerce stores product custom field data at the variant level, not on the product record. Custom field mapping for a product is therefore configured on Add/Update Zoho Commerce Product Variant FROM iPaaS.com, not on the product collection.
Setting one up has four parts, and all four are required:
Create the custom field in Zoho Commerce first. Zoho Commerce provides no way for the integration to create a custom field, so it must already exist in the store before the first transfer. Mapping to a custom field that has not been created there will not create it.
Define the matching custom field in iPaaS.com on the Product Variant collection. The iPaaS.com custom field belongs on that collection, not on the product collection.
Add the mapping on the Product Variant collection, setting the Zoho Commerce custom field's value from the iPaaS.com data you want the variant to carry.
Match the two by name. The Zoho Commerce custom field and the iPaaS.com custom field are paired by their names, so the two must agree.
Confirm in a staging environment that your custom field names align exactly, including capitalization, before relying on custom fields in production.
Because Zoho Commerce holds this data on the variant, a value that describes the product as a whole still has to be carried on each of its variants.
Mapping Collection Status
Status: Enabled. All three collections are active as configured.
Trigger Events: Product add and update events, subscribed under Outbound Data Flows in the subscription configuration. Whether a given transfer creates a new Zoho Commerce product or updates an existing one is decided by whether the iPaaS.com product is already linked by an external ID, not by which trigger fired. No products transfer automatically until those subscriptions are enabled, and Manual Sync is available whether or not they are. There are no separate triggers for either variant collection — variants reach Zoho Commerce when their product transfers.
Duplicate or Conflicting Mappings
No other mapping collection in this integration writes to the Zoho Commerce Product entity, so there is no competing source of truth to reconcile for products themselves.
The two variant collections write to the same Zoho Commerce entity as one another, but they are complementary rather than competing: each claims a different set of products through its mapping filter, based on whether the product is tracked at the variant level or the product level in iPaaS.com. A product travels down exactly one of them, and leaving both enabled is the intended configuration.
Review the mapping filters on both variant collections before enabling them and keep the routing intact. Widening either filter so that the same product qualifies for both would have two collections maintaining the same Zoho Commerce variant, with the last transfer to run deciding the result. If you change how a product is tracked in iPaaS.com, expect it to move from one collection to the other.
Collision handling is not implemented for these collections. Duplicate prevention relies on the external-ID link described under ID Format: once a product or variant has transferred, the stored Zoho Commerce identifier routes every later transfer to the existing record rather than creating a new one.
Unmapped field overwrite risk
Each product update rewrites the product in Zoho Commerce from a fixed set of values that is sent in full on every transfer, not only the values that changed. Anything outside that set is never sent and is left untouched in the store.
One consequence follows for subscribers or their MiSP: storefront visibility is transmitted on every update from the show_in_storefront mapping, which ships set to keep transferred products visible. A visibility change made directly in Zoho Commerce is overwritten on the next transfer. Subscribers who manage visibility per product should remap that field to a source that carries the intended value.
Supported Child Collections
Parent Collection: Add/Update Zoho Commerce Product FROM iPaaS.com. It has exactly two child collections:
Add/Update Zoho Commerce Product Variant FROM iPaaS.com — maintains the individual variants of a product tracked at the variant level, supplying each variant's SKU, prices, option values, opening stock figure and cost, and the link that attaches it to its parent product. Each variant saves its own external-ID link holding the Zoho Commerce variant ID.
Add/Update Zoho Commerce Simple Product Default Variant FROM iPaaS.com — maintains the single variant Zoho Commerce holds behind a product tracked at the product level, taking its SKU and prices from the product record. It resolves the Zoho Commerce product linked to that product and then that product's first variant.
Neither child is independently triggerable. Both are written as part of the parent product's transfer, and neither has a separate outbound trigger or Manual Sync entry point.
Stock levels are not maintained by any of these three collections, and the collections that maintain them are not child collections of the product. Add/Update Zoho Commerce Product Inventory FROM iPaaS.com and Add/Update Zoho Commerce Product Variant Inventory FROM iPaaS.com are standalone collections that run as their own transfers, and they are documented in the Zoho Commerce Inventory Mapping Documentation article.
Zoho Commerce Caveats
Administrator access and Organization ID: the connected Zoho account must have Administrator privileges, and the Organization ID must be configured in the subscription's connection settings. Although the Organization ID is presented as optional, product transfers depend on it and will not reach Zoho Commerce without it.
Authentication is tied to the United States Zoho accounts domain: the integration signs in through Zoho's US accounts service, and there is no setting that changes which regional service is used. A store whose Zoho organization is hosted on a data center outside the United States cannot currently connect, so no collection in this integration can transfer for that store.
Connection testing does not validate credentials: the connection test reports success without confirming that the credentials, token or Organization ID are correct. A successful test is not evidence that transfers will work — confirm with a Manual Sync of a single product before relying on automatic transfers.
Stock is held against a variant: Zoho Commerce does not hold stock on the product record itself, which is why every product has at least one variant behind it and why stock is maintained through the inventory collections.
A cost is required on product updates: Zoho Commerce accepts an opening stock figure with no cost when a product is first created, but it rejects a product update whose stock cost is negative or zero.
Unique storefront URL: Zoho Commerce expects each product to have a distinct storefront address. Because the URL is generated from the product name, validate in a staging environment that your product names generate unique URLs.
Custom fields must pre-exist: a Zoho Commerce custom field mapped on the Product Variant collection must already have been created manually in the store. See Custom Field Support.
Option values must have an attribute to belong to: a variant's option values are only meaningful when the product carries the matching attribute names, which are supplied by the product collection.
Configurable attributes are limited to three, text only: a product sold across more than three option dimensions cannot carry all of them through these collections, and the attributes are declared as text attributes only. Option values that need a different presentation in the storefront have to be set up directly in Zoho Commerce.
Category assignment is single-value and name-matched: a product is assigned to at most one Zoho Commerce category, chosen by exact, case-sensitive name match, and an unmatched assignment is skipped without an error. A product can therefore transfer successfully with no category at all.
Category matching costs one category-list read per assigned category: each of a product's category assignments is resolved with its own lookup against the store's full category list, on every transfer. A product carrying several assignments therefore multiplies those reads each time it syncs, which matters to the call volume of a catalog-scale run.
Call volume matters on large runs: Zoho does not publish a call quota for the Zoho Commerce store API, and a store may still refuse calls made too quickly. Every product and every variant written is a call against the store. When transferring a large catalog, stagger the work rather than sending everything at once, and validate throughput in a staging environment before a bulk load.
Rejection messages: when Zoho Commerce refuses a product or a variant, the message recorded by iPaaS.com is the response returned by Zoho Commerce. Read the message text to identify the field or condition the store objected to. Errors appear under Dashboard / Integration Monitoring / Error Logs.
iPaaS.com Caveats
Categories must be transferred first: a product's category assignment only resolves against a category that already exists in Zoho Commerce. Transfer categories through Add/Update Zoho Commerce Category FROM iPaaS.com before, or alongside, the products that reference them. The integration does not transfer a product's categories on its behalf.
Source records must exist: products are built from iPaaS.com Product records, which must exist and be current for these collections to transfer them.
The external-ID link decides add versus update: once a product has transferred, its external-ID link routes every later transfer to an update. Clearing that link causes the next transfer to create a second Zoho Commerce product.
Tracking method decides which variant collection applies: whether a product is tracked at the product level or the variant level in iPaaS.com determines which of the two variant collections maintains its variants. Changing a product's tracking method moves it from one collection to the other.
The parent product must be linked: a variant can only attach to a Zoho Commerce product once that product has transferred and saved its link. Because variants travel with the product, this is established during the product transfer. If a variant transfer reports that it cannot find its product, transfer the parent product first and re-run.
Custom field definition location: the iPaaS.com custom field used for a Zoho Commerce product custom field must be defined on the Product Variant collection, not on the product collection.
Setup Requirements
iPaaS.com Configuration
Open the subscription configuration and navigate to Outbound Data Flows, then subscribe to the Product add and update triggers that should dispatch this mapping collection. Until those subscriptions are enabled, no products transfer automatically. Manual Sync from the iPaaS.com Manual Sync page is available whether or not the triggers are enabled.
Leave both variant collections enabled. They are routed by their mapping filters and each claims a different set of products, so disabling one leaves that set of products without a maintained variant.
Zoho Commerce Configuration
Confirm the connected Zoho account has Administrator privileges and that the Organization ID is populated in the subscription's connection settings. Create any custom fields you intend to map in the store before the first transfer, because the integration cannot create them. Beyond that, no product-specific setup is required in Zoho Commerce — connection setup is covered in the Zoho Commerce Connections and Settings article and the Zoho Commerce Installation Instructions article.
Integration Flow
A Product add or update event is raised in iPaaS.com, or a subscriber runs a Manual Sync for a specific iPaaS.com Product record ID.
The integration checks whether that product already carries a Zoho Commerce external-ID link.
The product's category assignment is resolved by matching each assigned category name against the categories that already exist in Zoho Commerce, and the first match is applied.
If no link exists, the product is created in Zoho Commerce. If a link exists, the existing Zoho Commerce product is updated in place.
The product's variants are carried in that same operation, so each variant is created or updated with its full mapped field set. Which variant collection supplies those values is decided by the mapping filters: a product tracked at the variant level is handled by the Product Variant collection, and a product tracked at the product level is handled by the Simple Product Default Variant collection.
The product is read back so the identifiers Zoho Commerce assigned to the product and to each of its variants can be captured and saved as external-ID links for later transfers.
Ongoing stock levels are not part of this sequence. They are maintained by the two inventory collections, which run as their own transfers.
Mappings
Add/Update Zoho Commerce Product FROM iPaaS.com
iPaaS.com data type: Product
Description: Creates and updates Zoho Commerce storefront products from iPaaS.com Product records, and carries the product's variants in the same transfer.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Zoho Commerce) | Description |
Field | Product Name | name | Required. Sets the product's name, which identifies the product throughout the storefront and in search results. The storefront URL is also derived from it, so a product that transfers without a name has neither a usable title nor a usable address. Map a source that reliably supplies a non-empty value. |
Field | Product Sku | Sku | Recommended so the product carries the same stock-keeping identifier in both systems. This is the product-level SKU, not the SKU held on each variant; variant SKUs are supplied by the variant collections, and the variant SKU is what stock and ordering are tracked against in Zoho Commerce. |
Field | Product Description | description | Recommended so the storefront has product content to show. Products transfer successfully without it, and the product is created or updated with no description when the source value is empty. |
Field | Product Description | product_description | Recommended. Populates the second description Zoho Commerce presents alongside the product, drawn from the same iPaaS.com Description so the product reads consistently wherever the storefront surfaces it. Subscribers who need the two to differ can point this mapping at a different source field. |
Field | Product Unit | unit | Optional. Sets the product's unit of measure, for example each, box or kg. The product is created or updated with no unit when the source value is empty. Map it where the unit is meaningful to shoppers or to the way stock is counted. |
Field | Product SalePrice | salesPrice | Recommended so the product carries a price customers can buy at. If the source value is empty the product transfers without a selling price. |
Field | Product DefaultPrice | defaultPrice | Recommended. Sets the list price the storefront can show alongside the selling price. Products transfer successfully without it, and the product is created or updated with no default price when the source value is empty. |
Dynamic Formula |
| category_id | Recommended for subscribers who want products to appear under storefront categories. Resolves the product's iPaaS.com category assignments to a Zoho Commerce category by name. Products transfer successfully without a category assignment. |
Dynamic Formula | Product Name, reduced to a storefront address | url | Recommended. Builds the product's storefront URL from the product name: spaces become hyphens, unsupported characters are removed, and runs of hyphens are then collapsed to a single hyphen. Subscribers who maintain their own URL scheme can point this mapping at a source field carrying it instead. |
Static |
| show_in_storefront | Recommended. Controls whether the product is visible on the storefront, and it ships set to make transferred products visible. The value is a designed constant rather than an environment-specific example, so it does not need to be replaced during implementation. Because it is sent on every update, a visibility change made directly in Zoho Commerce is overwritten on the next transfer. |
Static |
| variant_type | Required. Identifies the product as an inventory-tracked product so its variants hold stock levels the inventory collections can maintain. The value is a designed constant that the product, variant and inventory collections all depend on, not an environment-specific example, so leave it as configured rather than changing or removing it. |
Dynamic Formula | Product Options — the name of the first option | attribute_name1 | Recommended for products sold in options, because the attribute name is what shoppers see above the option selector. When the product has at least one option defined in iPaaS.com its name is sent; when it has none, no value is sent and the product is created or updated without configurable attributes. It resolves to no value on simple products, which is correct for them. |
Dynamic Formula | Product Options — whether a first option exists | attribute_type1 | Recommended for products sold in options, because the attribute name on its own does not tell Zoho Commerce how to present the attribute. When the product has at least one option the attribute is declared as a text attribute; when it has none, no value is sent. |
Dynamic Formula | Product Options — the name of the second option | attribute_name2 | Optional. Names the product's second configurable attribute, for example Color where the first attribute is Size. When the product has a second option its name is sent; when it does not, no value is sent. It applies only to products sold in more than one option dimension. |
Dynamic Formula | Product Options — whether a second option exists | attribute_type2 | Optional. Declares the second configurable attribute as a text attribute when the product has a second option, and sends no value when it does not. It pairs with attribute_name2 and is subject to the same text-only limitation as the first attribute type. |
Dynamic Formula | Product Options — the name of the third option | attribute_name3 | Optional. Names the product's third configurable attribute, and it is the last of the three configurable attributes this collection supports. It applies only to products sold across three option dimensions. |
Dynamic Formula | Product Options — whether a third option exists | attribute_type3 | Optional. Declares the third configurable attribute as a text attribute when the product has a third option, and sends no value when it does not. It pairs with attribute_name3. |
Dynamic formula reference
The complete formulas behind the Dynamic Formula rows above, exactly as they ship.
url:
var result = Name;
result.Replace(" ","-");
result.Replace("---","-");
result.Replace("--","-");
Regex rgx = new Regex("[^a-zA-Z0-9-_]");
return rgx.Replace(result, "");
attribute_name1:
if (Options != null){
if (Options.count > 0){
var option1Name = Options[0].OptionName;
return option1Name;
}
}
return "";
attribute_name2:
if (Options != null){
if (Options.count > 1){
var option2Name = Options[1].OptionName;
return option2Name;
}
}
return "";
attribute_name3:
if (Options != null){
if (Options.count > 2){
var option3Name = Options[2].OptionName;
return option3Name;
}
}
return "";
attribute_type1:
if (Options != null){
if (Options.count > 0){
return "text";
}
}
return "";
attribute_type2:
if (Options != null){
if (Options.count > 1){
return "text";
}
}
return "";
attribute_type3:
if (Options != null){
if (Options.count > 2){
return "text";
}
}
return "";Category resolution behavior
Each of the product's category assignments is resolved by looking up the Zoho Commerce category whose name matches, and the matching category is applied to the product. Four behaviors matter when relying on it:
Matching is by exact name, including capitalization. A category named Shoes in iPaaS.com will not match a category named shoes in Zoho Commerce. Name categories identically on both sides.
A Zoho Commerce product accepts a single category, so where a product carries several category assignments in iPaaS.com only the first match is applied.
A category assignment with no matching Zoho Commerce category is skipped silently. No error is raised and the product still transfers, just without that assignment.
The match is made against categories that already exist in Zoho Commerce, so transfer categories through Add/Update Zoho Commerce Category FROM iPaaS.com before the products that reference them.
Each assignment is resolved with its own read of the store's category list, on every transfer. A product carrying several assignments therefore costs several full category-list reads each time it syncs, and a product carrying many of them takes longer to transfer than one carrying a single assignment. Keeping the number of assigned categories small reduces API consumption on catalog-scale runs.
Product URL generation
Because the storefront URL is derived from the product name, two consequences follow. Renaming a product changes its storefront URL, and links to the previous address will no longer resolve — plan product renames with that in mind. Two products whose names reduce to the same value produce the same URL, and storefront addresses need to be distinct, so validate the generated URLs in a staging environment before relying on them in production, particularly where product names differ only by punctuation.
Product-level pricing
Product-level pricing maps straight across: the iPaaS.com sale price populates the product's selling price and the iPaaS.com default price populates the product's default price. At the variant level the two prices are deliberately crossed, so if a storefront price does not read the way you expect, review the variant collection that applies to the product as well as this one.
Add/Update Zoho Commerce Product Variant FROM iPaaS.com
iPaaS.com data type: Product Variant
Parent Collection: Add/Update Zoho Commerce Product FROM iPaaS.com. Variants are not independently triggerable — they are written as part of their parent product's transfer.
Mapping Filter
SourceTypeName == "ProductVariantResponse" && Parent.TrackingMethod == "Variant"
Filter Description. This collection processes a record only when both conditions hold: the product it belongs to is tracked at the variant level in iPaaS.com, and the record is an actual variant record on that product. Anything else is passed over — a product tracked at the product level never reaches this collection, and neither does the product record itself. Nothing is rejected with an error message: a record that does not match is simply not processed here.
That is the routing half of a deliberate pair. Zoho Commerce creates a variant behind every product, including a product with no configurable options at all, which is why the integration provides two variant collections. The filter on this collection claims products tracked at the variant level; the filter on Add/Update Zoho Commerce Simple Product Default Variant FROM iPaaS.com claims products tracked at the product level. Between them a product travels down exactly one, no product is processed by both, and leaving both collections enabled is the intended configuration.
Description: Creates and updates the individual variants of an option-driven product in Zoho Commerce from iPaaS.com Product Variant records.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Zoho Commerce) | Description |
Field | Product Variant Sku | sku | Required. Sets the variant's SKU, which is the identifier stock, orders and fulfilment are tracked against in the store. A variant with no SKU value cannot be written to Zoho Commerce, and the transfer fails rather than creating an unidentified variant. Map a source that reliably supplies a SKU for every variant. |
Field | Product Variant SalePrice | rate | Recommended so that every variant carries a price customers can buy at. This is the price a shopper pays for the variant. If the source value is empty the variant transfers without a selling rate. |
Dynamic Formula |
| product_id | Required. Attaches the variant to its parent product by looking up the Zoho Commerce product already linked to the iPaaS.com parent product. It resolves automatically, so no source field needs to be chosen for it, and it can only resolve once the parent product has transferred. |
Field | Product Variant DefaultPrice | label_rate | Recommended so the storefront can show a list price alongside the selling price. Variants transfer successfully without it, and the variant is created or updated with no label rate when the source value is empty. |
Dynamic Formula | Product Variant Options — the value of the first option | attribute_option_name1 | Recommended for option-driven products, because it is what distinguishes one variant from another in the storefront option selector — for example Small, where the product's first attribute is Size. When the variant has at least one option its value is sent; when it has none, no value is sent. |
Dynamic Formula | Product Variant Options — the value of the second option | attribute_option_name2 | Optional. Supplies the variant's value for the product's second configurable attribute, for example Blue where the second attribute is Color. It applies only to variants distinguished by more than one option dimension. |
Dynamic Formula | Product Variant Options — the value of the third option | attribute_option_name3 | Optional. Supplies the variant's value for the product's third configurable attribute, and it is the last of the three option values this collection supports. Variants distinguished by more than three option dimensions cannot carry all of them. |
Dynamic Formula | Product Variant inventory — the total across all stocking records | initial_stock | Recommended so that a newly created variant starts with a stock position rather than at zero. It totals the variant's full iPaaS.com inventory and sends that figure; if the total comes out below zero, zero is sent instead. This is an opening figure, not ongoing stock maintenance. |
Dynamic Formula |
| initial_stock_rate | Required. Supplies the unit cost recorded against the variant's opening stock figure, which Zoho Commerce uses for stock valuation and cost reporting. Placeholder value — replace during implementation: the value shipped with this mapping is 1, which stands in for a real cost rather than representing one. |
Dynamic formula reference
The complete formulas behind the multi-line Dynamic Formula rows above, exactly as they ship.
attribute_option_name1:
if (Options != null){
if (Options.count > 0){
var option1Value = Options[0].Value;
return option1Value;
}
}
return "";
attribute_option_name2:
if (Options != null){
if (Options.count > 1){
var option2Value = Options[1].Value;
return option2Value;
}
}
return "";
attribute_option_name3:
if (Options != null){
if (Options.count > 2){
var option3Value = Options[2].Value;
return option3Value;
}
}
return "";
initial_stock:
var result = await SumFullInventoryForVariantAsync(Convert.ToInt64(Id)); if (result < 0 ) return "0"; return result.ToString();
Opening stock cost is a placeholder
Zoho Commerce accepts an opening stock figure with no cost when a product is first created, but a cost is required on subsequent product updates, and a negative or zero cost is rejected. Leaving the initial_stock_rate mapping in place is what keeps those updates from failing, so replace the value rather than removing the mapping. Subscribers or their MiSP who rely on Zoho Commerce for stock valuation, margin or cost-of-goods reporting must replace it with a mapping that supplies the variant's actual cost before the first transfer, otherwise every variant is valued at a unit cost of 1.
Variant pricing is crossed by design
The price mapping on this collection is deliberately crossed: the variant's selling rate comes from the iPaaS.com SalePrice, while its label rate comes from DefaultPrice. That pairing is by design — the storefront sells at the sale price and shows the default price as the crossed-out list price beside it. Do not swap the two without confirming the effect on your storefront pricing.
Opening stock is a snapshot
The stock figure sent with a variant is an opening position recorded when the variant is created, not ongoing stock maintenance. It is a total across the variant's iPaaS.com inventory rather than the level at one location, so where stock is tracked across several locations the combined total is what Zoho Commerce receives, and a total below zero is sent as zero so a negative stock position is never pushed to the storefront. Day-to-day stock is maintained by Add/Update Zoho Commerce Product Variant Inventory FROM iPaaS.com.
Which values on this collection actually reach Zoho Commerce depends on how the variant is written. See Variant field transmission under Additional Notes before relying on the label rate or the opening stock figure.
Add/Update Zoho Commerce Simple Product Default Variant FROM iPaaS.com
iPaaS.com data type: Product Variant
Parent Collection: Add/Update Zoho Commerce Product FROM iPaaS.com. This collection is not independently triggerable — it processes as part of the parent product's transfer.
Mapping Filter
Parent.TrackingMethod == "Product" && SourceTypeName == "ParentOnly"
Filter Description. This collection processes a record only when both conditions hold: the product is tracked at the product level in iPaaS.com — a simple product with no options — and the record is being processed as part of that product's own transfer rather than as a separate variant record. Anything else is passed over, including every product tracked at the variant level. Nothing is rejected with an error message: a record that does not match is simply not processed here.
That is the other half of the routing pair. Zoho Commerce creates a variant behind every product, including a product with no configurable options at all, and holds SKU, price and stock against that variant rather than against the product record. A simple product therefore still has one variant behind it in the store, and this collection is what keeps that automatically created variant in step with the product. Products tracked at the variant level are claimed by Add/Update Zoho Commerce Product Variant FROM iPaaS.com instead. Between the two, a product travels down exactly one, and leaving both enabled is the intended configuration.
Description: Maintains the single variant Zoho Commerce holds behind a simple product, using data taken from the parent Product record in iPaaS.com.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Zoho Commerce) | Description |
Dynamic Formula |
| sku | Required. Sets the SKU on the variant Zoho Commerce holds for the simple product, taken from the parent product's SKU. Because a simple product has no options of its own, its variant carries the product's own SKU, and a variant that arrives without one cannot be reconciled against stock or orders. |
Dynamic Formula |
| rate | Recommended so the product carries a price customers can buy at. It is taken from the parent product's sale price. If the parent product has no sale price the variant transfers without a selling rate. |
Dynamic Formula |
| product_id | Required. Attaches the variant to its parent product by looking up the Zoho Commerce product already linked to the iPaaS.com parent product. It resolves automatically, so no source field needs to be chosen for it. |
Dynamic Formula |
| label_rate | Recommended so the storefront can show a list price alongside the selling price. It is taken from the parent product's default price, and the variant is created or updated with no label rate when the parent product has no default price. |
Dynamic Formula | Parent product's Zoho Commerce link, resolved to that product's first variant | variant_id | Required for updates. Identifies which Zoho Commerce variant this collection is maintaining, by resolving the Zoho Commerce product already linked to the parent product and then taking that product's first variant. It resolves automatically and needs no source field. If the parent product has not yet transferred, no variant is resolved and there is nothing to update. |
Dynamic Formula | Parent product inventory — the total across all stocking records | initial_stock | Recommended so that a newly created product starts with a stock position rather than at zero. It totals the parent product's full iPaaS.com inventory and sends that figure; if the total comes out below zero, zero is sent instead. This is an opening figure, not ongoing stock maintenance. |
Dynamic Formula |
| initial_stock_rate | Required. Supplies the unit cost recorded against the variant's opening stock figure, which Zoho Commerce uses for stock valuation and cost reporting. Placeholder value — replace during implementation: the value shipped with this mapping is 1, which stands in for a real cost rather than representing one. |
Dynamic Formula |
| attribute_option_name1 | Optional. Deliberately supplies no first option value, because a simple product has no configurable options for its variant to carry. Leave it as configured: sending an option value for a product that has no options would create an option dimension in the storefront that the product does not actually have. |
Dynamic Formula |
| attribute_option_name2 | Optional. Deliberately supplies no second option value, for the same reason as the first. It is present so this collection covers the same set of variant fields as the option-driven variant collection. Leave it as configured. |
Dynamic Formula |
| attribute_option_name3 | Optional. Deliberately supplies no third option value, for the same reason as the first two. Leave it as configured. Products that genuinely need option values belong on Add/Update Zoho Commerce Product Variant FROM iPaaS.com. |
Dynamic formula reference
The complete formulas behind the multi-line Dynamic Formula rows above, exactly as they ship.
variant_id:
var parentProductId = await GetExternalIdAsync(Parent.Id, "Product", SpaceportSystemId);
if (parentProductId != null){
return await GetVariantIdByProductId(parentProductId);
} else {return null;}
initial_stock:
var result = await SumFullInventoryForProductAsync(Convert.ToInt64(Parent.Id)); if (result < 0 ) return "0"; return result.ToString();
Why the first variant is the one maintained
A product routed to this collection is expected to have exactly the one variant Zoho Commerce created for it, which is what makes taking the product's first variant the right behavior. If a product routed here has been given additional variants directly in the store, the collection would maintain whichever variant Zoho Commerce lists first. Keep products that genuinely need several variants tracked at the variant level in iPaaS.com, and validate the routing in a staging environment before relying on it in production.
Opening stock cost is a placeholder
Zoho Commerce accepts an opening stock figure with no cost when a product is first created, but a cost is required on subsequent product updates, and a negative or zero cost is rejected. Leaving the initial_stock_rate mapping in place is what keeps those updates from failing, so replace the value rather than removing the mapping. Subscribers who rely on Zoho Commerce for stock valuation, margin or cost-of-goods reporting must replace it with a mapping that supplies the product's actual cost before the first transfer, otherwise every product is valued at a unit cost of 1.
Variant pricing is crossed by design
The price mapping on this collection is deliberately crossed: the variant's selling rate comes from the parent product's SalePrice, while its label rate comes from the parent product's DefaultPrice. That pairing is by design — the storefront sells at the sale price and shows the default price as the crossed-out list price beside it. Do not swap the two without confirming the effect on your storefront pricing.
Opening stock is a snapshot
The stock figure sent here is an opening position recorded when the product is created, not ongoing stock maintenance. It is a total across the product's iPaaS.com inventory rather than the level at one location, so where stock is tracked across several locations the combined total is what Zoho Commerce receives, and a total below zero is sent as zero. Day-to-day stock is maintained by Add/Update Zoho Commerce Product Inventory FROM iPaaS.com, which is the collection that handles inventory for products tracked at the product level.
Because this collection only ever processes as part of the parent product's transfer, it always takes the write path that carries the full set of mapped variant fields. See Variant field transmission under Additional Notes.
Error Handling
Subscriber-visible errors raised during a product or variant transfer appear in the iPaaS.com Dashboard / Integration Monitoring / Error Logs.
Messages returned by Zoho Commerce — when the store refuses a product or variant write, the text recorded in the error log is the response Zoho Commerce returned, in the store's own wording, with the HTTP status appended. This is the channel through which most field-level problems surface: a required value missing, a storefront URL colliding with an existing product, a variant with no SKU, or a product update whose opening stock cost is zero or negative. Resolution: read the message text to identify the field or condition the store objected to, correct the source record or the mapping, and re-run the transfer.
Rejections raised when the store refuses calls made too quickly — Zoho does not publish a call quota for the Zoho Commerce store API, and a store may still refuse calls made too quickly. A refused call surfaces through the same channel as any other rejection, carrying the store's own wording. Resolution: stagger large catalog runs rather than sending everything at once, reduce the number of category assignments per product to cut the category-list reads each transfer performs, and validate throughput in a staging environment before a bulk load.
Connection and transport failures — where the store cannot be reached at all, the text recorded is the failure reported by the network layer rather than a message from Zoho Commerce. Resolution: confirm the connection is authenticated and the Organization ID is populated, then re-run. Note that a successful connection test does not by itself confirm that transfers will work.
Conditions that produce no error
Two behaviors change what a subscriber sees in Zoho Commerce without raising anything in the error log:
A product transfers successfully but carries no category when its assigned category name does not match a Zoho Commerce category exactly, including capitalization. The assignment is skipped silently. Confirm the names match, and that the categories have already transferred, rather than looking for an error.
A variant value does not appear in Zoho Commerce when the variant was written on its own rather than as part of its product, because part of the mapped field set is not carried on that path. Transfer the parent product so the full set is applied, and see Variant field transmission under Additional Notes.
Validation Rules
A variant SKU is mandatory: a variant with no SKU value cannot be written to Zoho Commerce. Enforcement is a failed transfer rather than a variant created without an identifier, so the condition is surfaced instead of being absorbed silently.
How a product is tracked decides which variant collection applies: enforced by the mapping filters on the two variant collections. A product tracked at the variant level is claimed by Add/Update Zoho Commerce Product Variant FROM iPaaS.com, and a product tracked at the product level by Add/Update Zoho Commerce Simple Product Default Variant FROM iPaaS.com. Enforcement is silent routing: a record that does not match a filter is passed over with no error for the other collection to claim.
An opening stock cost must be greater than zero on an update: Zoho Commerce accepts an opening stock figure with no cost when a product is first created, but rejects a product update whose stock cost is negative or zero. Enforcement is a rejection by the store, surfaced as the store's own message.
Testing & Validation
Test Scenarios
Create a new Product in iPaaS.com tracked at the product level and confirm it appears in the Zoho Commerce catalog with the expected name, both descriptions, unit and pricing, and that the variant behind it carries the product's SKU and prices.
Create a new Product tracked at the variant level with two or more variants and confirm each variant is created with the expected SKU, selling rate, label rate and option values, attached to the correct parent product.
Update the name and price on an existing, already-transferred product and confirm the change updates the same Zoho Commerce product rather than creating a second one, and that the storefront URL changes with the name.
Transfer a product whose assigned category name matches a Zoho Commerce category exactly and confirm the category is applied.
Transfer a product whose category name differs only by capitalization and confirm the product transfers without a category assignment and with no error raised.
Transfer a product carrying several category assignments and confirm only the first match is applied.
Attempt a variant transfer where no SKU value is supplied and confirm the transfer fails rather than creating an unidentified variant.
Run a Manual Sync using the iPaaS.com Product record ID and confirm the product and all of its variants transfer.
Re-transfer a previously transferred product and confirm the external-ID links route the transfer to the existing product and variants, with no duplicates created.
Replace the opening stock cost with a real cost, transfer, and confirm the product update is accepted and the value recorded against the variant is the one you supplied.
Confirm which of the two variant collections claimed each product by checking that a product tracked at the product level has a single maintained variant and a product tracked at the variant level has one per option combination.
Where custom fields are in use, transfer a product and confirm the value landed on the Zoho Commerce variant record rather than on the product record.
Validation Checklist
The product appears in Zoho Commerce with the name, both descriptions, unit and pricing supplied by iPaaS.com.
The storefront URL matches the value generated from the product name and is unique across the catalog.
Each variant is present, attached to the correct parent product, and carries its SKU, selling rate and option values.
The external-ID links are recorded against the iPaaS.com product and against each variant after the first successful transfer.
A second transfer updates the product and its variants in place; no duplicate product or variant is created.
Category assignment resolves for exactly-matching names and is skipped silently for non-matching names.
Exactly one of the two variant collections claimed each product, and both collections remain enabled.
The opening stock cost carries a real value rather than the shipped placeholder before any production transfer.
Any variant value that matters to you has been verified against the Zoho Commerce variant record rather than assumed.
Additional Notes
Variant field transmission
Two things write variant data, and they do not carry the same amount of it. This is subscriber-observable, so it is worth understanding before relying on any particular variant value.
When a variant is written as part of its parent product's transfer, the product write posts the variants alongside the product, and each variant is created or updated with the full set of mapped variant fields. This is the path every ordinary product transfer takes, and it is the only path the Simple Product Default Variant collection ever takes.
When a variant is written on its own, the request is reduced. It carries the SKU, the selling rate and the parent-product link; the variant's attribute name and its first attribute option value are both taken from the SKU value rather than from their own mappings; the opening stock cost and the second and third option values are not carried at all; and the label rate and the opening stock figure are sent as empty values rather than being left out. Sending an empty opening stock on an update is capable of disturbing the stock figure already stored against the variant in Zoho Commerce.
What to do about it: where a value on a variant collection matters to you, transfer the parent product so the full mapped set is applied, and validate in a staging environment that the value lands on the variant before relying on it in production. Subscribers who rely on the opening stock figure should also validate in a staging environment that a variant update does not clear the quantity already stored in Zoho Commerce. A SKU that is not meaningful as an option value can additionally produce storefront option labels that read oddly when a variant is written on its own, which is worth confirming in staging as well.
Out of scope
Product and variant deletion. Deleting a product or a variant in iPaaS.com does not remove it from Zoho Commerce. See Deleted Record Support.
Inbound product sync. These collections send products and variants from iPaaS.com to Zoho Commerce only. Changes made directly in Zoho Commerce are not read back into iPaaS.com through them.
Bulk initialization. Loading an existing Zoho Commerce catalog into iPaaS.com in one operation is not supported.
Automatic transfer of dependent records. The integration does not transfer a product's categories on its behalf. Categories are transferred by their own collection.
Independent variant transfer. Neither variant collection is separately triggerable; both transfer with the parent product.
Ongoing stock maintenance. Beyond the opening stock figure, stock is handled by the inventory collections rather than by these three.
Known limitations
The following describe behavior at the time this documentation was written.
Product and variant webhooks are not available. Changes made in Zoho Commerce do not notify iPaaS.com for products or variants. Transfers in this direction are driven by the iPaaS.com outbound triggers and by Manual Sync.
Category assignment is single-value and name-matched. A product is assigned to at most one Zoho Commerce category, chosen by exact, case-sensitive name match, and an unmatched assignment is skipped without an error.
The storefront URL changes when a product is renamed. Because the URL is derived from the name, renaming a product changes its storefront address and breaks existing links to the old one.
Configurable attributes are limited to three, text only. A product sold across more than three option dimensions cannot carry all of them, and attribute presentations other than text are not accommodated.
Opening stock is a snapshot, not maintenance. The stock figure sent by a variant collection reflects the iPaaS.com total at the moment of transfer. Later stock movement is only reflected once the relevant inventory collection runs.
Storefront visibility follows the mapped value. show_in_storefront ships pre-set and is sent on every update, so a change made directly in Zoho Commerce is overwritten on the next transfer. Subscribers who manage visibility per product should remap it to a source carrying the intended value.