Skip to main content

Pimcore Integration Known Limitations

Known limitations of the Pimcore integration, including one-directional transfer, direct-child variants, and category-assignment requirements.

The following are known limitations of the Pimcore integration at the time this documentation was written. They are inherent to the integration's design and to the Pimcore Datahub API, and they apply to all subscribers.

Platform Scope and Tested Versions

  • Remote platform: Pimcore, accessed through the Pimcore Datahub GraphQL API and Datahub webhooks.

  • Endpoint: each Pimcore instance exposes its own Datahub GraphQL endpoint, so there is no single shared base URL — the connection URL is specific to your Pimcore instance and Datahub configuration.

  • Reference data: the integration and its example mappings were validated against the Pimcore Cars demo data.

  • Not built for: writing data back into Pimcore; variant hierarchies deeper than direct children; category assignments that do not use a Many-To-Many Object Relation.


1. One-Directional Transfer (Pimcore to iPaaS.com only)

The integration transfers data from Pimcore into iPaaS.com. It does not create, update, or delete records in Pimcore.

What this means for you: Pimcore is the source of truth. Use this integration to bring Pimcore products, categories, variants, and related products into iPaaS.com; changes made in iPaaS.com are not written back to Pimcore. If you need to update Pimcore from another system, that is handled by a separate integration.


2. Direct-Child Variants Only

Only variants that are direct children of their parent product are transferred. Variant structures nested more than one level below the parent are not supported.

What this means for you: Model your variants as direct children of the parent product in Pimcore. If your data uses a deeper hierarchy, the deeper levels will not transfer as variants. If you need deeper variant support, contact iPaaS.com to request it.


3. Category Assignments Require a Many-To-Many Object Relation

Product and variant category assignments are supported only when the Pimcore relation is a Many-To-Many Object Relation to a class configured as a Product Category Class Name.

What this means for you: Configure your category relationship in Pimcore as a Many-To-Many Object Relation. Other relationship types will not be transferred as category assignments.


4. Referenced Records Must Exist in iPaaS.com First

Category assignments and related products are resolved to existing iPaaS.com records during a transfer. If a referenced category or related product has not yet been transferred, that reference is skipped rather than created.

What this means for you: Transfer parent categories before their child categories, and transfer the products that will be referenced before the relationships that point at them. If a relationship or category link is missing after a transfer, transfer the referenced record and re-run the transfer — the link resolves on the next pass.


5. No Bulk Initialization

The integration does not provide a bulk initialization that loads all existing Pimcore data in a single action.

What this means for you: To load existing data, use a scheduled poll or Manual Sync (a poll with no filter pulls recently modified records; a filter can target a broader set). To keep data current going forward, configure the Datahub webhook so changes transfer automatically.


6. Price Is Required at the Product Level

iPaaS.com requires a price on a product even when the source data holds price only at the variant level.

What this means for you: Ensure each product resolves a price. The example mappings demonstrate reading the parent price and falling back to the first variant price; adapt this to wherever price lives in your data so that no product transfers without one.


7. The classname Field Is Required for Linked Records

The integration builds the external ids that link records (category assignments, related products, and parent/child references) from each record's Pimcore class name. When the classname field is not available, a fallback prefix is generated that still produces a unique id but does not match when another record looks the same record up.

What this means for you: Define the classname field as a custom field wherever the Pimcore class exposes it (including on parent references). Without it, category assignments, related-product links, and category hierarchy can silently fail to resolve even though the records themselves transfer.


These 7 limitations reflect the integration's current design. For per-collection detail, see the mapping collection descriptions and the Pimcore mapping documentation.

Related Documents

Did this answer your question?