Skip to main content

iPaaS.com to Zoho Commerce Category Mapping Documentation

How iPaaS.com Product Category records create and update Zoho Commerce storefront categories, including the parent-first mapping filter, the field mappings, and the errors a category transfer can raise.

Summary

Zoho Commerce categories can be created and updated from iPaaS.com Product Category records through automatic outbound triggers or on-demand Manual Sync. Each transfer sends the category's name, description, storefront URL, hierarchy placement and storefront visibility, so the grouping structure that products are presented under stays in step with the source system. Category 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 Category record ID — the identifier of the category record in iPaaS.com that you want to transfer. Example: 1234.

Manual Sync is a platform feature that is always available, whether or not the automatic triggers are enabled.

External ID Format

After a category transfers successfully, iPaaS.com records the Zoho Commerce category ID as the external ID on a dedicated external-ID record for that category. Example: 4619534000000093222.

Subsequent syncs of the same category use that stored link to update the existing Zoho Commerce category rather than create a duplicate. Clearing the link causes the next transfer to create a new category in the store.

Deleted Record Support

Outbound delete is not supported for this collection. Deleting a Product Category in iPaaS.com does not delete the corresponding category in Zoho Commerce, delete mappings are not included in the default templates, and deletions do not propagate. Categories that are no longer wanted must be removed in Zoho Commerce directly.

Mapping Collection Status

Status: Enabled.

Trigger Events: Product Category add and update events, subscribed under Outbound Data Flows in the subscription configuration. No categories transfer automatically until those subscriptions are enabled.

Duplicate or Conflicting Mappings

No other mapping collection in this integration writes to the Zoho Commerce Product Category entity, so there is no competing source of truth to reconcile. The product collection reads Zoho Commerce category names in order to link a product to its category, but it does not create or modify categories.

Duplicate prevention

Duplicate prevention relies on the external-ID link described under ID Format. Once a category has synced, the stored Zoho Commerce category ID routes every later transfer to the existing category instead of creating a second one.

Unmapped field overwrite risk

Each category update rewrites the category in Zoho Commerce from a fixed set of values: the category name, description, storefront URL, parent placement, storefront visibility, navigation-menu inclusion, and the three storefront SEO values. Anything outside that set is never sent and is left untouched in the store.

Two consequences follow for subscribers or their MiSP:

  • Storefront visibility and navigation-menu inclusion are transmitted on every update from the visibility and show_in_menu mappings, which ship set to keep categories published and in the menu. A change made to either setting directly in Zoho Commerce is overwritten on the next sync. Subscribers who manage visibility per category should remap those two fields to a source that carries the intended value.

  • The storefront SEO values travel in the same update payload and are not part of the default mappings. Do not rely on SEO values entered directly in Zoho Commerce persisting across syncs — validate the behavior in a staging environment before relying on it in production.

Supported Child Collections

None. This is a standalone collection with no dependent child collections and no parent collection.

Categories do form a hierarchy among themselves through the parent_category_id mapping, but that is a relationship between category records, not a child mapping collection.

Zoho Commerce Caveats

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

  • Unique category URL: Zoho Commerce requires each category to have a unique storefront URL. This collection generates the URL from the category name and its subcategory trail. Categories whose names collide within the same branch can produce the same URL — validate in a staging environment that your category names generate unique URLs.

  • Parent category ordering: a parent category must exist in Zoho Commerce before a child category that references it can be created. Transfer categories from the top of the hierarchy downward. The mapping filter enforces this — see Mappings.

  • Category name matching is exact and case-sensitive: when products are synced, each product's category assignment is resolved to a Zoho Commerce category by exact name match, and matching is case-sensitive — a category named "Shoes" in iPaaS.com will not match "shoes" in Zoho Commerce. If several categories are assigned, the first name that matches is applied; a category with no matching name is skipped without an error and the product transfers without that category assignment.

  • 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. When syncing a large number of categories, stagger the work rather than sending everything at once, and validate throughput in a staging environment before a bulk load.

  • Error text comes from the store: when Zoho Commerce rejects a category write, the text recorded in the iPaaS.com error log is the store's own raw response rather than a rewritten message. See Error Handling.

iPaaS.com Caveats

  • Organization ID must be configured: category transfers will not reach Zoho Commerce unless the subscription's Organization ID is set in the connection settings. Confirm it is populated before enabling this collection.

  • Source records must exist: categories are built from iPaaS.com Product Category records. Those records must exist and be current in iPaaS.com for this collection to transfer them.

  • No dependency is transferred automatically: a parent category is not fetched and sent on behalf of a child. Ordering the transfers, or retrying the child after the parent lands, is the subscriber's responsibility.

Setup Requirements

iPaaS.com Configuration

Open the subscription configuration and navigate to Outbound Data Flows, then subscribe to the Product Category add and update triggers that should dispatch this mapping collection. Until those subscriptions are enabled, no categories transfer automatically. Manual Sync from the iPaaS.com Manual Sync page is available whether or not the triggers are enabled.

Zoho Commerce Configuration

No category-specific setup is required in Zoho Commerce beyond a connected store with an administrator-level account. The connection credentials and the Organization ID are configured once for the subscription — see the Zoho Commerce Connections and Settings article and the Zoho Commerce Installation Instructions article.

Integration Flow

  1. A Product Category add or update event is raised in iPaaS.com, or a subscriber runs a Manual Sync for a specific iPaaS.com Product Category record ID.

  2. The mapping filter evaluates the category's placement. A top-level category passes. A nested category passes only if its parent category already carries a Zoho Commerce link; otherwise the transfer stops with Parent category must be uploaded first.

  3. The integration checks whether the category itself already carries a Zoho Commerce external-ID link.

  4. If no link exists, the category is created in Zoho Commerce and the returned Zoho Commerce category ID is saved as the external ID for that record.

  5. If a link exists, the existing Zoho Commerce category is updated in place using the stored ID.

  6. The mapped values are written to the storefront catalog: name, description, generated storefront URL, parent placement, visibility and navigation-menu inclusion.

Mappings

Add/Update Zoho Commerce Category FROM iPaaS.com

iPaaS.com data type: Product Category

Mapping Filter

var external = await GetExternalIdAsync(ParentId, "Product Category", SpaceportSystemId);
if(IsEmpty(ParentId))
    return true;
else if(!IsEmpty(ParentId) && IsEmpty(external))
    throw new Exception("Parent category must be uploaded first");
else return true;

Filter Description. The filter enforces parent-before-child ordering. It first looks up the Zoho Commerce link — the external value — saved against the category's parent, then takes one of three branches:

  • The category has no parent. A top-level category always passes the filter and transfers.

  • The category has a parent, and that parent has already transferred. The parent's saved Zoho Commerce link is found, the category passes the filter, and it transfers attached beneath its parent.

  • The category has a parent, and that parent has not transferred yet. There is no link to attach the category to, so the transfer is stopped and reports Parent category must be uploaded first.

The third branch is a sequencing guard, not a permanent rejection. It self-resolves: once the parent category transfers, re-running the child record succeeds without any change to the mapping or the source data. Errors appear under Dashboard / Integration Monitoring / Error Logs.

Subscribers or their MiSP can edit this filter, but leaving it in place is recommended — it is what prevents a nested category from being created in the store without its parent link.

Description: Creates and updates Zoho Commerce storefront categories from iPaaS.com Product Category records, including the category's placement in the storefront hierarchy and its storefront visibility.

Mapping Type

Source Field (iPaaS.com)

Destination Field (Zoho Commerce)

Description

Field

Product Category Name

name

Required. Sets the category's name in the Zoho Commerce storefront catalog and category navigation. A category cannot be created in Zoho Commerce without a name, so leave this mapping in place. Category names are also the key used to match products to their categories during product sync — keep them unique and consistent.

Field

Product Category Description

description

Recommended. Sets the category description shown on the storefront category page. Categories transfer successfully without it, but mapping it gives shoppers fuller category information. If the source description is empty, the category is created or updated with no description.

Dynamic Formula

return await GetExternalIdAsync(ParentId, "Product Category", SpaceportSystemId);

parent_category_id

Required for any category that sits beneath another category. Looks up the Zoho Commerce category already linked to the iPaaS.com parent category and attaches this category beneath it. A top-level category has no parent and the mapping resolves to no value, which is correct. Because the link is resolved from the parent's saved external ID, the parent must already have transferred.

Dynamic Formula

Product Category Name, prefixed by the SubcategoryTrail where one exists, reduced to a storefront address

url

Required. Supplies the category's storefront URL rather than leaving Zoho Commerce to generate one. The value is built from the category name, prefixed with the category's subcategory trail when one exists, and reduced to a web-safe form. Renaming a category or moving it under a different parent changes its storefront URL.

Static

"true"

visibility

Required. Controls whether the category is visible on the storefront, and ships set to make categories visible. Zoho Commerce expects a visibility value on every category write, and each update sends whatever this mapping supplies — so leaving it mapped keeps categories published on every sync. Removing the mapping causes each update to send the category as not visible, which unpublishes it from the storefront.

Static

"true"

show_in_menu

Required. Controls whether the category appears in the storefront navigation menu, and ships set to include categories in the menu. It behaves the same way as visibility: the value is sent on every update, so leaving it mapped keeps categories in the navigation menu. Removing the mapping causes each update to drop the category from the menu.

Dynamic formula body — url

var result = Name;
if (SubcategoryTrail != null)
result = SubcategoryTrail + " > " + Name;
result.Replace(">","_");
result.Replace(" ","_");
result.Replace("___","_");
result.Replace("__","_");
Regex rgx = new Regex("[^a-zA-Z0-9-_]");
return rgx.Replace(result, "");

The separator between the trail and the name, and any spaces, become underscores; any character that is not a letter, a digit, a hyphen or an underscore is removed; and runs of underscores are then collapsed to a single underscore. Note that names reducing to the same value collide on a URL Zoho Commerce requires to be unique.

Controlling storefront visibility per category

visibility and show_in_menu ship as fixed values that keep every transferred category published and in the navigation menu, and both are sent on every update. Subscribers or their MiSP who want to control publishing per category should remap those two fields to a source field that carries the intended value, in place of the fixed values shipped here. Leaving them as delivered means category publishing is governed by iPaaS.com, not by the store.

Error Handling

Subscriber-visible errors raised during a category transfer appear under Dashboard / Integration Monitoring / Error Logs.

  • "Parent category must be uploaded first" — raised by this collection's mapping filter when a nested category is transferred before its parent category has been sent to Zoho Commerce. There is no saved Zoho Commerce link on the parent, so the child cannot be attached. Resolution: transfer the parent category first, then re-run the child. No mapping change is needed — the same record succeeds on retry once the parent lands. Transferring categories from the top of the hierarchy downward avoids the error entirely.

  • Messages returned by Zoho Commerce — when the store rejects a category create or update, the text recorded in the error log is the store's own raw response, carrying Zoho Commerce's wording rather than a rewritten message (for example, a required value missing or a storefront URL colliding with an existing category). Resolution: read the message to identify what the store objected to, correct the source record or the mapping, and re-run the transfer.

Conditions that produce no error

Two behaviors change what subscribers see in the storefront without raising anything in the error log:

  • A product's category assignment is skipped silently when its name does not match a Zoho Commerce category exactly, including capitalization. The product transfers without that category assignment. Confirm the names match rather than looking for an error.

  • Storefront visibility and navigation-menu inclusion are re-sent on every category update. A change made directly in Zoho Commerce is overwritten on the next sync with no error raised.

Validation Rules

  • Parent-before-child ordering: enforced by the collection's mapping filter. A nested category is not transferred until its parent category holds a Zoho Commerce link. Enforcement is a stopped transfer reporting Parent category must be uploaded first, which self-resolves on retry after the parent transfers.

  • A category name is mandatory: Zoho Commerce will not create a category without one. Enforcement is a rejection by the store, surfaced as the store's own message.

  • Storefront URLs must be unique: Zoho Commerce enforces uniqueness. The generated URL is derived from the category name and subcategory trail, so uniqueness follows from unique names within a branch. Enforcement is a rejection by the store.

Testing & Validation

Test Scenarios

  1. Create a new top-level Product Category in iPaaS.com and confirm it appears in the Zoho Commerce storefront catalog with the expected name, description and generated URL.

  2. Update the name on an existing, already-synced category and confirm the change propagates to the same Zoho Commerce category rather than creating a second one — and confirm the storefront URL changes with it.

  3. Transfer a category with an empty description and confirm the category is created successfully with no description.

  4. Transfer a nested category whose parent has already synced and confirm it appears beneath the correct parent in Zoho Commerce.

  5. Transfer a nested category whose parent has not synced and confirm the transfer stops with Parent category must be uploaded first; then transfer the parent, re-run the child, and confirm it succeeds without any mapping change.

  6. Run a Manual Sync using the documented iPaaS.com Product Category record ID and confirm the transfer succeeds.

  7. Re-sync a previously transferred category and confirm the external-ID link routes the transfer to the existing Zoho Commerce category so no duplicate is created.

  8. Unpublish a category directly in Zoho Commerce, re-sync it, and confirm the shipped visibility and menu values republish it — the expected behavior of the delivered mappings.

  9. Rename a category that products reference, re-sync the affected products, and confirm the product-to-category links resolve against the new name.

Validation Checklist

  • The category appears in Zoho Commerce with the name, description and storefront URL supplied by iPaaS.com.

  • A second transfer of the same category updates it in place; no duplicate category is created.

  • The external-ID link is recorded against the iPaaS.com Product Category record after the first successful transfer.

  • Nested categories appear beneath the correct parent, and a child transferred ahead of its parent reports the expected error and succeeds on retry.

  • Category visibility and storefront menu placement match expectations after an update.

  • Generated storefront URLs are unique across the catalog.

  • Products that reference the category resolve to it after both the category and the products have synced.

Additional Notes

The following describe behavior at the time this documentation was written.

  • Category URL changes on rename or re-parent: because the URL is derived from the name and hierarchy position, renaming a category or moving it under a different parent changes its storefront URL, and links to the previous URL will no longer resolve. Plan category renames with that in mind.

  • Category name changes affect product links: because products are matched to categories by exact, case-sensitive name, renaming a category breaks the link for products that referenced the previous name until those products are re-synced.

  • Storefront visibility follows the mapped values: visibility and menu placement are sent on every update from mappings that ship set to keep categories published. Changes made directly in Zoho Commerce to either setting are overwritten on the next sync.

  • Call volume matters on large runs: stagger a bulk category load rather than sending everything at once, and validate throughput in a staging environment first.

  • Inbound category sync is out of scope: this collection sends categories from iPaaS.com to Zoho Commerce only. Category changes made directly in Zoho Commerce are not read back into iPaaS.com through this collection.

  • Category deletion is out of scope: see Deleted Record Support.

Related Documents

Did this answer your question?