Summary

This document describes how Pimcore categories are transferred into iPaaS.com Product Categories. Categories are sent from Pimcore to iPaaS.com through the Datahub GraphQL API and webhooks, including their parent relationship so the iPaaS.com category hierarchy matches Pimcore. Categories are commonly transferred before products, because a product's category assignments resolve against categories that already exist in iPaaS.com.

The mapping collection shipped with a new Pimcore subscription is an example configuration built on the Pimcore Cars demo data. It demonstrates the technique; a real implementation uses a different Pimcore category class and fields, so treat the specific source paths and formulas as illustrative.

Related documents: The field-naming and external-id conventions used here are shared across the integration and are described in full in the Pimcore to iPaaS.com Product Mapping Documentation. For one-time setup, see the Pimcore Installation Instructions and Pimcore Connections and Settings.

How the Integration Works

Pimcore is the source system; data flows one way, from Pimcore to iPaaS.com. The integration does not create, update, or delete records in Pimcore.

A category changes in Pimcore and a Datahub webhook notifies iPaaS.com, or a subscriber initiates a Manual Sync or a scheduled poll.
The integration retrieves the category record — including its parent category — from the Pimcore Datahub GraphQL API.
The mapping collection transforms it into an iPaaS.com Product Category, resolving the parent category to its existing iPaaS.com id.
The category is created or updated in iPaaS.com, linked by its external id so later transfers update the same record.

External ID Format

After a successful transfer, iPaaS.com records the category against an external id in the form <ClassName>:<id> — for example Category:556. Defining the classname custom field is required for the integration to build this prefix; without it, the integration falls back to a generated prefix that still produces a unique id but will not match when a product's category assignment (or a child category's parent link) looks the category up by its <ClassName>:<id> external id. For a Manual Sync, enter the Pimcore category record id on the iPaaS.com Manual Sync page; for a bulk transfer, enter a Pimcore polling filter as the Manual Sync value.

Mapping Collection Status and Trigger Events

Status: the example category collection is Enabled.
Trigger Events: automatic transfers occur when a Pimcore Datahub webhook is configured for the category class (pimcore.dataobject.postAdd and pimcore.dataobject.postUpdate), configured on the Pimcore side. Manual Sync is always available.
Webhook prerequisite: automatic (webhook) transfers also depend on the required Pimcore Webhook Message collection, which receives all incoming Pimcore webhooks before they are routed. See the Pimcore to iPaaS.com Webhook Message Mapping Documentation; do not delete that collection.

Mappings

Add/Update Pimcore Product Category (Example) TO iPaaS.com

Transfers a Pimcore category to an iPaaS.com Product Category. This collection has no mapping filter, so every category received is processed.

Mapping Type	Source Field (Pimcore)	Destination Field (iPaaS.com)	Description
Field	`Category.name`	Name	Required. The category name.
Dynamic Formula	`GetSpaceportIdAsync("Product Category", ...)` on `Category:<parentId>`	ParentId	Recommended for category hierarchy. Reads the Pimcore parent category id, builds the external id `Category:<parentId>`, and resolves it to the matching iPaaS.com category id. The parent category must already exist in iPaaS.com.

To transfer the parent relationship, define custom fields for both the parent id and the parent classname (for example Category.parent.[on object_Category].id and Category.parent.[on object_Category].classname). The parent classname is required for the parent external id to be built and resolved; without it the parent link cannot be established.

System Caveats

Pimcore Caveats

Category class: one Pimcore class is designated as the Product Category type through the Product Category Class Names subscription setting.
Introspection: keep Datahub introspection enabled during setup so field names and paths can be discovered; it is not required afterward.

iPaaS.com Caveats

Parent category must exist first: the ParentId mapping resolves against an existing iPaaS.com category, so transfer parent categories before their children (or re-run the transfer once parents exist). An unresolved parent leaves the category without a parent link.

Deleted Record Support

This integration transfers data from Pimcore to iPaaS.com only. Outbound delete is not supported — category deletions in Pimcore are not propagated, and delete mappings are not included in the templates.

Known Limitations

At the time this documentation was written, the parent-category link resolves only to categories that already exist in iPaaS.com; a category transferred before its parent will not have a parent link until it is transferred again.
At the time this documentation was written, the integration is one-directional (Pimcore to iPaaS.com); it does not write back to Pimcore.

Testing & Validation

Test Scenarios

Configure the Datahub webhook and confirm that adding or updating a category in Pimcore transfers it to iPaaS.com.
Update a category name in Pimcore and confirm the change propagates on the next transfer.
Transfer a parent category, then a child category, and confirm the child's parent link resolves correctly.
Perform a Manual Sync using a Pimcore category record id and confirm the category is created or updated.

Category with resolved parent after transfer

Validation Checklist

Name is mapped for every category.
Custom fields are defined for the parent id and parent classname where category hierarchy is used.
Parent categories are transferred before their children.

Pimcore to iPaaS.com Product Category Mapping Documentation