This article describes the known limitations of the Zoho Commerce integration. They are inherent to the integration's current design and to the capabilities Zoho Commerce exposes through its API, and they apply to all subscribers at the time this documentation was written.

Each limitation is described twice: once in technical terms, and once in plain language under What this means for you, so that you can see both what the integration does and what to do about it. Where a limitation has a workaround, the workaround is stated. Where a limitation stops a record from transferring, the resulting message is cataloged in the Zoho Commerce Error Messages article.

This integration was built for Zoho Commerce, Zoho's hosted online store product.

Not built for. This integration connects to Zoho Commerce and to no other Zoho product. It is not built for, and does not support, Zoho CRM, Zoho Books, Zoho Inventory, Zoho Billing, Zoho Desk, Zoho Analytics, Zoho Sites, or any other application in the Zoho suite, even where those products share account credentials or data with a Zoho Commerce store. Records held in those products are outside its scope. If Zoho launches a separate commerce product line, or a materially different API generation for Zoho Commerce, this integration will not automatically support it.

No mapping collection in this integration deletes a record. Products, product variants, categories, inventory records, sales orders and their child records are added and updated only. Removing a record in one system does not remove or deactivate its counterpart in the other, and removing a line from an order in Zoho Commerce is not carried into iPaaS.com as a deletion of the captured line.

What this means for you: treat removal as a manual step in both systems. When you retire a product, a variant or a category, remove it in Zoho Commerce yourself, and use the storefront visibility fields to take a record out of the shopfront if you want it hidden rather than deleted. When an order is removed in Zoho Commerce, the transaction already captured in iPaaS.com stays in place and should be handled by your own downstream process. If deletion propagation matters to your workflow, describe the requirement to your iPaaS.com partner channel — input like this informs future enhancement releases.

No entity in this integration round-trips. Products, product variants, categories and inventory move outbound only, from iPaaS.com to Zoho Commerce. Sales orders and their lines, payments, taxes, discounts and addresses move inbound only, from Zoho Commerce to iPaaS.com. A change made directly in Zoho Commerce to a product, variant, category or stock level is not read back into iPaaS.com, and the integration does not create or update orders, order lines, payments, taxes, discounts, shipping methods, shipments, coupons or promotions in Zoho Commerce.

What this means for you: decide which system owns each kind of data and edit it there. iPaaS.com is the source of truth for catalog and stock; Zoho Commerce is the source of truth for orders. An edit made on the wrong side is either overwritten on the next transfer, in the case of catalog data, or simply never seen, in the case of order data.

Note: because nothing is bidirectional, there is no risk of the two systems overwriting each other's edits to the same record in opposite directions. The overwrite behavior that does apply is described in Unmapped fields on outbound updates below.

Zoho Commerce provides neither API access nor webhook notifications for the customer records held in its Member Portal. No integration can read them out or write them in, and this one does not attempt to. Customer address books held in Zoho Commerce are likewise not transferred; only the billing and shipping addresses recorded on an individual sales order are captured, and only as part of that order's transfer.

What this means for you: build your downstream processes around the customer email address and the addresses captured on each order rather than around a separately linked customer record in iPaaS.com. Where you need a customer master, maintain it in the system that owns it and match on the order's email address.

If your customer master is held in Zoho CRM, iPaaS.com offers a separate Zoho CRM integration that syncs those records. It is a distinct integration with its own subscription and its own mapping collections, and it is not configured or enabled from this one. Whether your Zoho Commerce customers appear in Zoho CRM depends on how your Zoho account links the two products, so confirm that in your own environment before planning around it.

The integration has no bulk initialization mode. There is no operation that loads an existing Zoho Commerce catalog into iPaaS.com in one pass, and no operation that pushes an entire iPaaS.com catalog to Zoho Commerce in one pass. Records transfer individually, either through the outbound triggers or through Manual Sync.

What this means for you: plan an initial load as a controlled run rather than a single button press. The supported approach for moving a large dataset is a bulk sync using Postman, which drives the same per-record transfers in a managed sequence. Stagger the run and validate throughput in a staging environment before loading a full catalog into production.

The integration does not fetch or transfer a record's dependencies on its behalf. Transferring a product does not transfer the categories that product is assigned to, and a category assignment only resolves against a category that already exists in Zoho Commerce. A nested category is stopped with an error if the category above it has not transferred yet.

What this means for you: transfer in dependency order. Move categories first, parents before children, then products. Where a product's category assignment finds no matching Zoho Commerce category, the product still transfers — it simply arrives without that assignment and with no error raised, so a missing category is easy to overlook. Verify a representative sample in the storefront after an initial load.

Product variants are not separately triggerable; they transfer as part of their parent product's transfer. The order child collections — order lines, payments, taxes, the header discount, and the billing and shipping addresses — are not separately triggerable either; they are captured as part of the parent sales order's transfer. There is no way to refresh a variant, a line, a payment, a tax record, a discount or an address on its own.

What this means for you: to refresh any of this detail, transfer the parent record. Transfer the product to refresh its variants; transfer the sales order to refresh its lines, payments, taxes, discount and addresses. Manual Sync takes the parent record's identifier, and the children travel with it.

Zoho provisions each organization in a regional data center and issues a region-specific account host for authentication. This integration authenticates against the United States host. A subscriber whose Zoho organization is provisioned in the European, Indian, Australian, Japanese, Canadian or any other non-United States region cannot complete the Authorize step, and cannot refresh a token once one has been issued.

What this means for you: confirm with your Zoho administrator which data center your Zoho organization is provisioned in before you begin the installation. If it is not the United States data center, the connection cannot be established, and you should raise the requirement through your iPaaS.com partner channel describing your region — input like this informs future enhancement releases. The failure surfaces during the Authorize step, and the resulting message is cataloged in the Zoho Commerce Error Messages article.

The connection test on the subscription reports success without confirming that the credentials, the issued token or the Organization ID are usable. A green result therefore proves only that the test ran, not that a transfer will succeed. Relatedly, the Organization_Id setting is presented as optional but is sent on every call the integration makes to Zoho Commerce; without it, no transfer can succeed.

What this means for you: do not treat a successful connection test as confirmation that the subscription is configured correctly. After completing the setup described in the Zoho Commerce Installation Instructions article, populate Organization_Id in the connection settings and then verify the connection by running a Manual Sync of one product and one sales order. Subscribers or their MiSP should confirm end to end in a staging environment that records transfer as expected before switching off any manual process that depends on them, and before enabling the automatic triggers in production.

Zoho does not publish a call quota for the Zoho Commerce store API, and a store may still refuse calls made too quickly. There is therefore no documented figure to design a run against. Every record the integration writes or reads is a call against the store, and some operations cost more than one: a product transfer reads the product back after writing it, an inventory adjustment reads the current stock level before writing the difference, and each category assignment on a product is resolved with its own lookup. A large catalog load, a large inventory run, or a catch-up capture of many sales orders in a short window therefore concentrates a great deal of traffic on one store.

What this means for you: stagger large jobs rather than sending everything at once, and avoid running several intensive jobs against the same store concurrently. Because no published figure exists to tune towards, validate throughput in a staging environment before a bulk load or before relying on high-volume automatic capture in production. Where the store refuses a call, the affected records can be transferred again once it accepts traffic normally.

Zoho Commerce product and category events do not trigger an inbound capture into iPaaS.com, and they do not notify iPaaS.com that an outbound record needs refreshing. The same applies to product variants. Only sales order events reach iPaaS.com from Zoho Commerce.

What this means for you: catalog and stock data moves outbound on the iPaaS.com outbound triggers and on Manual Sync, and there is no event-driven path in the other direction. Make catalog and stock edits in iPaaS.com so they flow to Zoho Commerce on the next transfer. An edit made directly in the storefront stays local to Zoho Commerce until the next outbound transfer of that record overwrites it.

A product's storefront address is derived from its name: spaces become hyphens, characters that are not a letter, digit, hyphen or underscore are removed, and runs of hyphens are collapsed to one. A category's storefront address is derived from its name and its position in the hierarchy. Two consequences follow. Renaming a product, or renaming or re-parenting a category, changes its storefront address and breaks existing links to the old one. And two products whose names reduce to the same value produce the same address, which Zoho Commerce expects to be unique.

What this means for you: treat a rename as a change to a public web address. Where product names differ only by punctuation, validate the generated addresses in a staging environment before relying on them in production. Subscribers or their MiSP who maintain their own address scheme can point the product url mapping at a source field that carries it, which removes the dependency on the name entirely.

A product's storefront category is resolved by matching the product's iPaaS.com category assignment to a Zoho Commerce category with the same name, compared exactly, including capitalization. A Zoho Commerce product accepts a single category, so where a product carries several assignments only the first match is applied. An assignment with no matching category is skipped silently: no error is raised and the product transfers without it. Renaming a category in either system therefore breaks the match for products that referenced the previous name, until those products are transferred again.

What this means for you: name categories identically on both sides, and keep the names stable. A product named against "Shoes" in iPaaS.com will not match a Zoho Commerce category named "shoes". Because a failed match produces no error, verify category placement in the storefront after an initial load and after any category rename, and re-transfer the affected products.

Storefront visibility is sent on every outbound transfer. For products, the show_in_storefront value is sent on every update. For categories, both visibility and show_in_menu are sent on every update, and both are sent whether or not they are mapped — when they are left unmapped, they are sent as "not visible" and "not in menu", which takes the category off the storefront and out of the navigation menu. A change made directly in Zoho Commerce to any of these three settings is overwritten on the next transfer of that record.

What this means for you: map visibility and show_in_menu on the category collection and treat them as required, not optional. As delivered they are set to keep categories published and in the menu; leaving them unmapped hides your categories on the next sync without raising an error. Manage storefront visibility from the mapped source rather than in the storefront: subscribers or their MiSP who set visibility per product or per category should point these fields at a source field that carries the intended value.

Update behavior differs by collection, and each behavior is deliberate. A product update sends only the fields that are mapped; fields you have not mapped are omitted from the request, so values already held in Zoho Commerce against those fields are left as they are. A category update sends a fixed set of fields — name, description, storefront address, visibility, menu placement, the three search-engine fields and the parent category — and the storefront visibility and menu placement within that set are always sent, as described above. A variant written on its own sends a reduced set, described in the next limitation.

What this means for you: for products, you can map a subset of fields and keep the rest maintained in Zoho Commerce. For categories, anything outside the fixed set stays under Zoho Commerce's control, but visibility and menu placement do not — map them. Where you want a value on a mapped field to come from Zoho Commerce rather than from the source system, use a destination-value mapping so the existing Zoho Commerce value is sent back unchanged instead of being replaced.

A variant written as part of its parent product's transfer carries its full mapped field set. A variant written directly through the variant collection carries a reduced set — its stock-keeping unit, its price and its parent product reference. Fields such as the barcode identifiers, part number, package details, reorder level, order quantity limits, purchase cost, tax, status, description and variant custom field values are available to map and can be mapped without error, but they are not carried on a direct variant write. The same reduced set applies whether the variant is being created or updated by that collection.

What this means for you: transfer the parent product when the full mapped field set needs to reach Zoho Commerce, and validate the result in a staging environment before relying on a direct variant write. Because a field that is not carried produces no error, a variant can appear to transfer successfully while the value you expected never arrives — check the variant in the storefront after the first transfer of each pattern you rely on.

A product tracked at the product level in iPaaS.com — a simple product with no options — is represented in Zoho Commerce by a single variant behind the product record, and the integration maintains that product's first variant. No option values are sent for such a product, because it has none. A product that has been given extra variants directly in the Zoho Commerce store may therefore not have the variant you expect maintained.

What this means for you: where a product genuinely needs several variants, track it at the variant level in iPaaS.com so it routes to the option-driven variant collection instead. Avoid adding variants directly in Zoho Commerce to a product that is tracked at the product level in iPaaS.com, since only the first will be maintained by later transfers.

A product sold in options carries its option dimensions on the product record and the individual option values on its variants, and the integration accommodates three of each. Attributes are declared as text only. A product sold across more than three option dimensions cannot carry all of them, and an option that needs a different presentation in the storefront — a swatch, for example — cannot be configured through the integration.

What this means for you: where a product needs more than three option dimensions, or an option presentation other than plain text, set that product up directly in Zoho Commerce and exclude it from the transfer using a mapping filter. Subscribers or their MiSP can add that filter on the product collection in the iPaaS.com mapping page.

The stock figure sent with a variant is an opening figure that reflects the iPaaS.com total at the moment of transfer; it is not ongoing maintenance. Later stock movement reaches Zoho Commerce only when the relevant inventory collection runs. Alongside the opening figure, Zoho Commerce accepts a product created with no stock cost, but requires a cost on every subsequent product update and rejects a cost that is negative or zero. The initial_stock_rate mapping is what supplies that cost, so the mapping has to stay in place and carry a usable value or later product updates fail.

What this means for you: keep the initial_stock_rate mapping in place and replace its delivered value with your real cost rather than removing the mapping — see Placeholder Values to Replace Before Go-Live below. Maintain ongoing stock through Add/Update Zoho Commerce Product Inventory FROM iPaaS.com or Add/Update Zoho Commerce Product Variant Inventory FROM iPaaS.com, and do not rely on the product or variant transfer to keep levels current.

Zoho Commerce accepts a stock change as a difference rather than as an absolute figure, so the integration always sends a difference. There is no operation that sets a stock level directly, and no operation that removes an inventory record. Each transfer maintains one quantity, for one stocking unit, at the single location supplied on that transfer; the integration does not distribute a quantity across several Zoho Commerce locations or reconcile levels between them.

What this means for you: where your stock is held across several Zoho Commerce locations, run a transfer per location rather than expecting one transfer to apportion a total. Confirm the locations you intend to adjust exist in the store before the first run. Where a level in Zoho Commerce has drifted, transferring the record again recalculates the difference against the level then current and brings it back into line.

Because iPaaS.com supplies a target quantity and Zoho Commerce accepts only a difference, each adjustment reads the current level from Zoho Commerce, calculates the difference, and then writes it. The two steps are not a single operation, so anything that changes the level between them is not accounted for. Two adjustments for the same stocking unit running at the same time both read the same starting level and both apply their full difference, leaving the final quantity wrong. A storefront sale landing between the read and the write is likewise not reflected in the calculated difference.

What this means for you: stagger mass inventory jobs rather than running them concurrently against the same records, and prefer quieter trading periods for large stock runs. Where a level has ended up wrong, transferring the record again corrects it, because the next adjustment is calculated from the then-current level.

The integration holds a list of the payment methods you have accounted for in your mappings. An order paid with a method on the list is captured normally. An order paid with a method not on the list is stopped and raised as an error rather than being captured as a partial record needing manual repair. The comparison is against the payment method name exactly as Zoho Commerce records it on the order, so a difference in spelling or capitalization is treated as an unlisted method. Introducing or renaming a payment method in the storefront without updating the list stops every order paid with it from that moment.

What this means for you: this list is delivered with placeholder entries and must be replaced before your first transfer — see Placeholder Values to Replace Before Go-Live below. Until it is, no real orders are captured at all. Add every payment method you accept, and add each new one at the point you introduce it in the storefront. Orders stopped for this reason are captured successfully when they are transferred again through Manual Sync after the list is corrected. The resulting error is cataloged in the Zoho Commerce Error Messages article.

The integration records what Zoho Commerce reports about an order's payment. It does not take, authorize, capture, refund or otherwise move money, and it does not create or update payments in Zoho Commerce. The captured payment status is applied as a fixed value rather than read from the payment, so it does not reflect the payment's actual state in the payment processor.

What this means for you: treat the captured payment as a record of what the storefront reported at the time the order transferred, not as a live payment state. Where your downstream process needs a true payment state, subscribers or their MiSP can remap the status field to a source that carries it, or derive the state downstream from your payment processor. All money movement stays in Zoho Commerce and your payment provider.

An order's Zoho Commerce status is captured through a translation that pairs each Zoho Commerce status with an iPaaS.com value. An order whose status has no pair in that translation is captured without a status value; the rest of the order transfers normally.

What this means for you: review the Order Status translation before go-live and add a pair for every status your storefront can produce, including any custom status. Where orders have already been captured without a status, add the missing pair and transfer those orders again through Manual Sync to fill it in.

Every captured order child record — the lines, the payment, the tax, the header discount and the billing and shipping addresses — reflects the order as it stood at the moment it transferred. Changes made to the order in Zoho Commerce afterwards do not flow through on their own, and there is no way to refresh a child record without transferring the parent order.

What this means for you: where an order is edited in Zoho Commerce after it was captured, transfer that order again through Manual Sync to bring the captured detail up to date. Build any downstream reconciliation around the expectation that captured order detail is a point-in-time snapshot rather than a live view.

An order produces a tax record only when it carries at least one tax entry, and a header discount record only when it carries an order-level discount. A tax-free order produces no tax record, and an order with no discount, or with a discount applied per line rather than to the order, produces no header discount record.

What this means for you: any downstream process that expects a tax record or a discount record on every order needs to account for their absence rather than treating it as a failure. Nothing is missing when they do not appear; the order simply carried no such detail.

The integration captures the figures Zoho Commerce holds, in the shape Zoho Commerce holds them. An order taxed by more than one authority is captured as a single combined amount with the order's tax name and rate, so the individual authorities cannot be separated out. A header discount carries the amount and its order-level marker but not the promotion or coupon that produced it, and tax recorded against an individual line is captured with that line rather than in the order's tax record. A line captures only the discount applied to that item, so line values will not reconcile to the order total on an order discounted at the order level. A line with a quantity of zero records its list rate as the unit price rather than a calculated per-unit figure; the transfer still completes.

What this means for you: reconcile at the level Zoho Commerce reports. Read order-level discount and tax from the order and its header discount and tax records, and read line-level discount and tax from the lines, rather than expecting one to sum to the other. Where you need per-authority tax detail or the identity of the promotion that produced a discount, that information stays in the Zoho Commerce order and has to be read there.

A multi-line street address is captured as a single comma-separated value, so the original line breaks cannot be recovered downstream. The contact name on both the billing and the shipping address is taken from the order's contact detail rather than from the address itself, so an order shipped to a third party carries the ordering contact's name on the captured shipping address. Where an order carries several contacts, only the first contributes its name.

What this means for you: confirm in a staging environment that the flattened street value is acceptable to your fulfillment and finance processes before relying on it. Where you send gifts or ship to third parties, confirm how the captured shipping contact reads for those orders and adjust your downstream handling accordingly.

Two values are delivered as placeholders and must be replaced before your first transfer. Both are edited by subscribers or their MiSP on the iPaaS.com mapping page for the collection named, and both require a redeploy afterwards.

This article describes 27 known limitations of the Zoho Commerce integration, together with the two placeholder values that must be replaced before go-live. For the detailed technical behavior of any individual mapping collection — its filters, field mappings, prerequisites and system caveats — see that collection's description on the iPaaS.com mapping page, and the long-form mapping documentation articles listed below.