This article documents known limitations and important behaviors of the iPaaS.com Shopify integration so you know what to expect and how to work around each one.

Scope: the full Shopify integration. Limitations are grouped into the areas below (use the article's table of contents to jump to a section):

Areas covered: Locations · Customers · Companies / B2B · Products & Variants · Inventory · Product Categories · Orders · Returns · Gift Cards · Cross-cutting behaviors.

Location reactivation uses the Shopify Admin GraphQL locationActivate mutation, which requires the @idempotent directive introduced in Shopify Admin API version 2026-04. The reactivate-before-update behavior — where a Shopify location found in a deactivated state is reactivated before an update is applied — therefore requires the connection to be on API version 2026-04 or later. The default API Version preset is 2026-01; on an earlier version the activation step can fail. Creating and updating locations otherwise operate on whichever API version the connection is configured to use.

What this means for you: if your locations may need to be reactivated during an update, set the Shopify connection's API Version to 2026-04 (or later). Validate the setting in a staging environment before relying on activation in production.

Shopify's location model includes a fulfillsOnlineOrders flag (whether a location fulfills online orders), and the locationAdd / locationEdit mutations accept and return it. The integration's Location does not currently expose this field, so it cannot be mapped in either direction.

What this means for you: a location's online-order fulfillment setting is not synchronized by this integration. Set it manually in the Shopify admin if your business requires it.

The Shopify integration includes an inbound Shopify Location To iPaaS collection that maps only the location Name. Because the iPaaS.com API replaces the entire record on update, when a location you sent to Shopify is echoed back through that inbound collection, fields that are not mapped there — Parent, Type, and Description — are overwritten with empty values on the iPaaS.com Location.

What this means for you: if you set Parent, Type, or Description on an iPaaS.com Location, add a Dynamic Formula mapping on the Shopify Location To iPaaS collection that preserves each field (for example, map DestinationValue.Description to the iPaaS.com Description field) so the value is retained instead of cleared. See the iPaaS.com to Shopify Location Mapping Documentation for the full mitigation.

This integration never deactivates or deletes a Shopify location. It only reactivates a location it needs to update, when it finds a matched location in a deactivated state. Deactivating or deleting a location is a manual action performed in the Shopify admin under a supervised process.

What this means for you: removing a location from Shopify is a manual step; it is not driven from iPaaS.com.

Shopify enforces unique location names, including across deactivated locations. Before a location is linked by external id, the integration matches existing locations and recovers from duplicate-name conflicts using the Name. Renaming a location in iPaaS.com before it has been synced (and therefore linked) at least once can cause a new Shopify location to be created instead of updating the intended one.

What this means for you: sync a location once to establish its external-id link before renaming it, and keep location names unique within your store.

Creating or updating a Shopify location requires a country that Shopify recognizes. The country is mapped from the iPaaS.com Location address; if it cannot be resolved to a valid Shopify country, the transfer fails.

What this means for you: ensure each Location's address country is set to a value Shopify accepts.

Shopify enforces a unique email per customer. When a customer transfer would create a duplicate email, the integration links to the existing Shopify customer by email instead of creating a new one — but a customer with no email cannot be de-duplicated this way and may create a duplicate. Shopify also expects a valid province/state abbreviation; the integration normalizes the iPaaS.com Region, but an unrecognized value is passed through unchanged and may be rejected.

What this means for you: give customers a valid, unique email and a recognized province/state code. Deleting a customer is only propagated when the Delete collection is configured.

Companies require Shopify's B2B capability to be enabled (available on Basic, Grow, Advanced, and Plus as of April 2026 — see the iPaaS.com to Shopify Company Mapping Documentation). When transferring FROM iPaaS.com, the integration de-duplicates by company name unless the Allow Creating Duplicate Companies subscription setting is enabled; when that setting is on, the de-duplication AND the automatic related-Customer prerequisite are both skipped, so unlinked contacts are dropped. Company contacts always depend on their related Customer existing (TO iPaaS.com) or being linked to Shopify (FROM iPaaS.com).

What this means for you: enable B2B on the store, and leave Allow Creating Duplicate Companies off unless you specifically intend a new company on every transfer (and have pre-linked the related customers).

Every Shopify variant must define at least one option value, and the total variant count is capped by the store's Shopify plan limit — products that exceed it are rejected. Before an external-id link exists, products and variants are matched to Shopify by SKU/title, so non-unique SKUs can mis-link or duplicate. Shopify's default placeholder option ("Title" / "Default Title") is intentionally excluded by the option/option-value filters.

What this means for you: ensure each variant has at least one real option value, keep SKUs unique, and stay within your plan's variant limit.

Inventory levels can only be set where the location is linked in Shopify and inventory tracking is enabled for the item at that location. Inventory tied to an unlinked location, or to an untracked item, will not update.

What this means for you: sync locations first and enable inventory tracking on the items/locations you intend to manage from iPaaS.com.

Recent Shopify Admin API versions (2026-04 and later) require a "change from" quantity on an inventory update; the integration always supplies it, so inventory syncing keeps working with no configuration on your part (verified against Shopify Admin API version 2026-07 and the 2026-01 default preset at the time this documentation was written). The ChangeFromQuantity field on the inventory From-iPaaS.com collections controls how each update is applied, and the collections ship it set to a static true. With it true, an update is applied only when Shopify's current on-hand quantity still matches what iPaaS.com last knew; if another process changed the quantity between syncs, that line is rejected rather than overwriting the change. Setting it to false — or leaving it unmapped — applies the update unconditionally so it always succeeds, which is the legacy behavior existing subscribers receive by default.

What this means for you: the shipped default (true) guards against overwriting a concurrent change, at the cost of rejecting an inventory line when Shopify's quantity has diverged (reported under Dashboard / Integration Monitoring / Error Logs). If you would rather every inventory update always succeed regardless of concurrent changes, set ChangeFromQuantity to false on the inventory collections. Validate the behavior in a staging environment before relying on it in production.

Shopify collections do not support a parent/child hierarchy through the API, so an iPaaS.com category hierarchy cannot be reproduced in Shopify — a browsable hierarchy must be arranged manually in the Shopify navigation (Menu). Collection SortOrder must be one of Shopify's supported values; an unrecognized or empty value is sent as PRICE_ASC by default. Before an external-id link exists, a category is matched to a Shopify collection by exact Title (case-insensitive); when several share a title, the one with the most products is linked.

What this means for you: manage category hierarchy on the iPaaS.com side (and Shopify navigation), keep collection titles distinct, and expect PRICE_ASC when no sort order has been captured.

Duplicate-order prevention depends on the Shopify Metafield for Transaction Number Matching subscription setting (documented in Shopify Connections and Settings): the integration links an existing Shopify order by that metafield instead of creating a duplicate, but the metafield must exist in Shopify and be filterable. For how the matching works end to end, see the iPaaS.com to Shopify Order Mapping Documentation. A line item's product is auto-created in Shopify only when Create Line Item Product as Prerequisite is enabled; otherwise a missing product fails the order. Customer and product prerequisites must succeed or the whole order transfer fails. Deleting an order in iPaaS.com is not propagated to Shopify.

What this means for you: configure the transaction-number metafield (created and filterable in Shopify) to avoid duplicate orders, and enable Create Line Item Product as Prerequisite if your orders may reference products not yet in Shopify.

A return can be pushed to Shopify only once the entire order it references is fulfilled. The integration treats anything short of fully fulfilled — including a partially fulfilled order — as not yet returnable, so the return is not created. This is a workflow constraint: a source system that raises a return against an order whose remaining lines have not shipped cannot sync it until fulfillment completes.

What this means for you: complete fulfillment of the whole order before pushing a return. If a return is rejected with a message about the order not being fulfilled, confirm every line on the order has shipped (see Shopify Error Messages).

Shopify's return lifecycle is terminal. From an open return you can either close it or cancel it, but once a return is closed or cancelled it cannot be reopened, cancelled, or otherwise re-transitioned. An attempt to cancel a return that is already closed is rejected by Shopify, and a change that re-opens or re-classifies a completed return in your source system will not propagate to Shopify.

What this means for you: decide a return's final state — closed or cancelled — at the point it is completed. Changes made to an already-finished return in your source system will not carry across to Shopify.

Returns have no mappable tax field. Shopify calculates the taxes on a return itself, and the integration cannot set or override them. Subscribers used to mapping tax fields on the iPaaS.com Transaction should not expect the same control on a return.

What this means for you: treat return taxes as Shopify-computed; do not attempt to map tax values onto a return.

Each return line's reason must be one of Shopify's fixed values (for example UNWANTED, DEFECTIVE, or OTHER), spelled exactly and in the correct case. A free-text or human-readable reason is rejected, and a reason of OTHER additionally requires a note. The full list of values and the exact error appear in Shopify Error Messages.

What this means for you: map your source return reasons onto Shopify's fixed values (case-sensitive) using a Lookup Translation so an unmapped reason is caught in iPaaS.com rather than at Shopify, and supply a note whenever the reason is OTHER.

At the time this documentation was written, the returns flow creates, closes, and cancels returns. It does not create refunds, does not approve or decline return requests, and does not process exchanges (exchange line items). These are handled in the Shopify admin.

What this means for you: use the integration to sync the return record and its open / closed / cancelled state; handle refunds, request approvals or declines, and exchanges directly in Shopify.

When a Shopify return is imported into iPaaS.com, it is linked to the original order's iPaaS.com Transaction. At the time this documentation was written, a return whose original order is not yet present in iPaaS.com is rejected with an error rather than imported without its parent — returns are never left as orphans.

What this means for you: import (or allow the integration to import) the original order before its returns. If a return is rejected for a missing parent, import the order first and re-transfer the return.

When an already-imported return is transferred to iPaaS.com again, header-level values you have edited in iPaaS.com are retained, but line-level monetary values on the return lines are reset to the incoming Shopify values. At the time this documentation was written, per-line monetary fields (for example a unit or extended price) are not preserved across a re-import, although the header values — transaction number, email, tax, shipping, subtotal, and total — are.

What this means for you: if you maintain per-line monetary values on a return in iPaaS.com, expect them to be overwritten with Shopify's values when the return is re-imported. If your process only needs a return's status to stay current, you can disable or remove the return line update collection during implementation so existing line values are left untouched; the header status will still update.

When a return shipping fee is sent to Shopify, the fee amount can be mapped from the source transaction, but at the time this documentation was written the currency is sent as a static USD by default. Shopify requires the fee to be expressed in the order's presentment currency.

What this means for you: if your store transacts in a currency other than USD, change the return shipping fee currency mapping to your store's currency before enabling the return shipping fee. If no fee amount is mapped, no fee is applied and no error occurs.

Gift cards are supported through the Add/Update Shopify Plus Gift Card TO iPaaS.com collection (reads Shopify gift cards into iPaaS.com for reporting) and the Add Shopify Plus Gift Card FROM iPaaS.com collection (one-time creation of gift cards in Shopify). Several Shopify platform constraints apply:

What this means for you: treat the FROM-iPaaS.com gift card flow as a one-time migration (seeding existing balances into Shopify), not an ongoing balance sync; request the read_gift_cards / write_gift_cards scopes from Shopify Support before enabling; keep gift card values within Shopify's caps; and expect gift cards to reach iPaaS.com through order and bulk processing rather than instantly on creation.

The iPaaS.com API replaces the entire record on update, so any field not mapped on an inbound (TO iPaaS.com) collection is overwritten with empty/null each time that collection runs. This is documented above for Locations (Parent, Type, Description), and the same mechanism applies to other entities whose inbound collections map only a subset of fields.

What this means for you: for any field you maintain in iPaaS.com that the inbound collection does not map, add a Dynamic Formula preservation mapping (for example DestinationValue.<Field>) on that collection so the value survives inbound updates.

Only Product Category TO iPaaS.com supports bulk initialization (see Shopify Connections and Settings). Other entities are not initialized in bulk; they transfer through their normal webhook/outbound triggers, Manual Sync, or order-processing cascades.

What this means for you: do not expect a one-click bulk backfill for entities other than Product Category; seed other data via Manual Sync or normal processing.

This article documents 24 known limitations grouped into ten areas of the Shopify integration.