Jasper PIM Integration - Known Limitations

The following are the known limitations of the iPaaS.com Jasper PIM integration. They are inherent to the current design of the integration and to the capabilities of the Jasper PIM API, and apply to every subscriber.

This integration is built for Jasper PIM and calls the Jasper Standard PIM v1 API (/api/v1). Subscribers connect against their Jasper PIM tenant host — either the older *.oci-1.jasperpim.com pattern or the newer *.pim.jasperpim.com pattern. See the Jasper PIM Connections and Settings article for the supported subscription settings and authentication scheme.

Last validated end-to-end against the live Jasper PIM Standard PIM v1 API on 2026-06-02.

Not built for:

This integration does not expose a one-click bulk or initial-load button on the iPaaS.com Subscription Settings page. Subscribers cannot select "transfer everything" to push an existing iPaaS.com catalog into a freshly installed Jasper PIM tenant in a single operation.

What this means for you: When you need to seed a Jasper PIM tenant with a large existing catalog (Products, Categories, Inventory, Options, Option Values, Variants), use the platform-standard bulk sync using Postman workaround. Iterate parent-before-child (Categories first, then Products, then per-product child rows). For ongoing day-to-day operation after the initial seed, Manual Sync and outbound trigger events are the supported paths.

The Jasper PIM integration operates in the From iPaaS direction only. Every transfer is dispatched outbound from iPaaS.com to the subscriber's Jasper PIM tenant. There is no inbound (To iPaaS) pull path and no webhook receiver from Jasper PIM into iPaaS.com.

What this means for you: Changes made directly in the Jasper PIM admin UI (or through any other tool that writes to Jasper PIM) are not pulled back into iPaaS.com by this integration. iPaaS.com remains the source of truth for the catalog data the integration transfers. Subscribers who need bidirectional sync today should contact iPaaS.com Support to discuss alternative patterns.

When iPaaS.com transfers a record for the first time, the integration does not search Jasper PIM for a pre-existing record that might already match (for example, a Product with the same SKU, or an Inventory row at the same location). If a matching record already exists in Jasper PIM — because it was created manually, imported by a different tool, or seeded outside of iPaaS.com — the integration creates a new record rather than linking to the existing one. For Products, the duplicate-SKU create call may even fail outright with a unique-SKU error from Jasper PIM.

What this means for you: Before turning on automatic transfers against an existing Jasper PIM tenant that already contains data, either delete the pre-existing Jasper PIM records that would conflict, or pre-populate the iPaaS.com cross-reference (the external-ID link table) so subsequent transfers route to the correct existing Jasper PIM records. The Postman bulk-sync workaround referenced in Limitation 1 is a common path for capturing those initial cross-reference links.

The Inventory mapping collections do not search Jasper PIM for an existing inventory row at the same (product, location) pair before creating a new one. If the external-ID cross-reference is missing for a given inventory record and an inventory row already exists in Jasper PIM at that location, the integration will create a second inventory row rather than reconcile against the existing one.

What this means for you: Subscribers seeding an existing Jasper PIM tenant should pre-populate the inventory cross-reference (for example, via the Postman bulk-sync workaround in Limitation 1) before enabling automatic inventory transfers in volume. Without that, the destination tenant may accumulate duplicate inventory rows for products whose inventory was previously created outside iPaaS.com.

Jasper PIM Attributes are tenant-wide — every attribute defined on any Product becomes part of the Attribute catalog that appears against every other Product in the tenant. When the Product write path encounters an iPaaS.com custom field whose name does not yet exist as a Jasper PIM Attribute, it creates a new Attribute. That Attribute then surfaces against every product in the tenant.

What this means for you: Review the iPaaS.com custom-field configuration carefully before enabling the Product collection in production. An unintended custom-field name (or a typo on a single iPaaS.com product) can introduce a new Attribute that subsequently appears against every product in the Jasper PIM tenant. Subscribers who rely on a curated Attribute catalog in Jasper PIM should validate the iPaaS.com side first.

Once an Option Value record exists in Jasper PIM under a given casing (for example, Red or red), sending a differently cased value through this integration will not update the stored casing. Jasper PIM returns the pre-existing record rather than rewriting its case. The pre-existing casing is preserved.

What this means for you: Correcting the casing of an existing Option Value requires direct cleanup in the Jasper PIM admin UI. If consistent casing across Jasper PIM Option Values matters to your downstream consumers, normalize the casing in the iPaaS.com source before the first transfer creates the record.

The default Product Inventory mappings cover the on-hand inventory count only. Jasper PIM's inventory record exposes a separate held inventory field for stock that is reserved against pending orders or otherwise not available for sale; this integration does not include that field in its default mapping set.

What this means for you: Subscribers (or their MiSP) who track held / reserved inventory separately in their source system and want it reflected in Jasper PIM can add a mapping for that field to the Product Inventory or Product Variant Inventory mapping collection. Without that customization, only the on-hand count is synchronized.

The on-hand inventory count on Jasper PIM is a whole-number type. The integration does not pre-validate or transform source inventory values before sending them. Behavior with fractional source quantities (e.g., 1.5) or negative source quantities (e.g., -3) is not documented by Jasper PIM — fractional values may be rejected or truncated, and Jasper PIM has not published whether it accepts or rejects negative on-hand quantities.

What this means for you: Subscribers whose source system can produce fractional or negative inventory should validate end-to-end behavior in a non-production Jasper PIM tenant before enabling the inventory collections in production. If the source data type ever emits values outside the typical "whole positive integer" range, confirm the behavior staging before relying on it.

For the Update Jasper PIM Product Variant Inventory FROM iPaaS.com (standalone) collection, if the source row omits the Quantity Available value, the Count On Hand mapping defaults to 0. This overwrites the existing Jasper PIM stock count for the variant at that location.

What this means for you: Confirm that the source system reliably populates the Quantity Available value for every variant inventory row before enabling this collection. Otherwise, occasional missing-value source rows can silently zero out the corresponding variant inventory in Jasper PIM.

The iPaaS-side feature catalog advertises a granular per-attribute update endpoint that matches the public Jasper PIM API reference. The shipped integration writes per-attribute updates against the collection-level attribute endpoint instead. Jasper PIM accepts the collection-level write in current production tenants, so subscribers see no immediate failure — but the runtime path is not the canonical Jasper PIM API reference path.

What this means for you: Subscribers who rely on per-attribute updates should validate the behavior in a non-production Jasper PIM tenant before enabling the Product collection in production. If a future Jasper PIM API change ever requires the granular path, the integration will need an update before continuing to write attribute changes reliably.

The above 10 limitations describe the current scope and behavior boundaries of the iPaaS.com Jasper PIM integration. For detailed per-collection technical documentation, see the mapping collection descriptions linked from each mapping collection in the iPaaS.com portal, and the Jasper PIM Help Center collection for the full set of subscriber-facing articles.