This article describes the known limitations of the commercetools integration. These limitations are inherent to the integration's current design, to the shipped default mapping configuration, and to the capabilities the commercetools HTTP API exposes. They apply to every subscriber, and every one of them was true at the time this documentation was written.

The commercetools integration connects an iPaaS.com subscription to a commercetools Composable Commerce project across twenty-one mapping collections. It carries orders, order line items, order taxes, order addresses, order payments, customers and customer addresses into iPaaS.com, and it publishes products, product variants, variant options, product attribute definitions, categories, locations and inventory out to commercetools. The design intent is a catalogue-out, transaction-in split: commercetools is treated as the storefront of record for shopper and order activity, and iPaaS.com is treated as the system of record for catalogue and stock. The limitations below describe where that design stops.

Areas covered: regional and currency scope · transfer timing, polling and failure recovery · overwrite and deletion behavior · dependency ordering · catalogue and inventory constraints · order and payment intake · platform quotas · placeholder values to replace before go-live.

Read this article alongside the commercetools Installation Instructions and commercetools Connections and Settings. Failures that produce a message are catalogued in commercetools Error Messages; the limitations below are the behaviors that do not produce a message.

Remote platform. This integration is built for commercetools Composable Commerce, accessed through the commercetools HTTP API.

Host. The integration reaches the commercetools project through the regional API host recorded in the subscription's API Url setting, in the form:

Authentication is performed against a commercetools authorization host. commercetools operates a separate authorization host for each region and instructs clients to "use the authorization URL according to the Region your Project is located in" (https://docs.commercetools.com/api/authorization, retrieved 2026-07-20). This integration authenticates against the us-central1.gcp authorization host only. See section 1.

API version. The commercetools HTTP API is unversioned. This integration was built against the production commercetools HTTP API as it stood on 2026-07-20, and against integration version 1.0.0.

Scope of validation. This documentation was produced from a direct review of the integration's shipped behavior and of the default mapping configuration delivered with it, current as of 2026-07-20. A formal end-to-end acceptance test record does not accompany this release, so no tested-version claim beyond the above is made here. Subscribers or their MiSP validate the flows they intend to use in a staging project before production cutover.

Not built for. This integration is built for commercetools Composable Commerce and for nothing else. It is not built for other products in the commercetools portfolio — its storefront, checkout and extension-marketplace offerings are separate products with separate APIs and are outside this integration's scope. It is not built for any other composable, headless or hosted commerce platform. A commercetools project that is not a Composable Commerce project is not a supported target.

At the time this documentation was written, the integration authenticates against the us-central1.gcp commercetools authorization host, and that host is fixed. It is not derived from the API Url the subscriber supplies. commercetools publishes five regional authorization hosts — auth.us-central1.gcp, auth.us-east-2.aws, auth.europe-west1.gcp, auth.eu-central-1.aws and auth.australia-southeast1.gcp, all under commercetools.com — and instructs clients to use the one matching the region their project is located in (https://docs.commercetools.com/api/authorization, retrieved 2026-07-20). A subscriber whose commercetools project sits in any of the other four regions cannot obtain a token, and therefore cannot transfer anything, no matter what credentials are entered.

Combined with the pricing behavior described in section 2, this means the integration is effectively United States–only as shipped. This is the single most consequential limitation in this article, and it is a scope boundary rather than a configuration option: there is no setting that changes it.

What this means for you. Confirm the region of your commercetools project before you begin. If it is hosted in the us-central1.gcp region, the integration authenticates normally. If it is hosted in any other region, the integration cannot connect at all, and no combination of API Url, Client_Id, Client_Secret and Scope values will make it connect — see commercetools Connections and Settings for those credentials. Subscribers or their MiSP who need another region should raise a feature request with iPaaS.com Support at support@ipaas.com so that multi-region authentication can be scoped for a future release.

At the time this documentation was written, every price this integration writes into commercetools — on a product and on a product variant alike — is labelled United States dollars and placed in a United States price scope. The currency label and the price country are fixed values, not values read from the iPaaS.com record. A subscriber selling in euros, pounds sterling or any other currency has each price written into commercetools carrying the wrong currency, even where the numeric amount itself is right.

What this means for you. If your catalogue is priced in United States dollars for the United States market, prices arrive correctly. If it is priced in any other currency, do not rely on this integration to publish prices: transfer the rest of the catalogue and maintain prices directly in commercetools, or repoint the price mappings and validate the result in a staging project before go-live. Subscribers or their MiSP who need multi-currency price publishing should raise a feature request with iPaaS.com Support at support@ipaas.com.

At the time this documentation was written, every monetary value the integration converts assumes the currency has two decimal places. commercetools records money in the smallest unit of the currency together with the number of decimal places that currency uses; this integration converts by a fixed factor of one hundred in both directions rather than reading the decimal count from the record. This affects the order total, subtotal, shipping charge, tax amount, discount amount, line unit price, original unit price, extended price, estimated tax amount and payment amounts on the inbound side, and product and variant prices on the outbound side.

The conversion is correct for two-decimal currencies such as the United States dollar and the euro. It is wrong by a factor of one hundred for zero-decimal currencies such as the Japanese yen and the South Korean won, and wrong by a factor of ten for three-decimal currencies such as the Bahraini dinar and the Kuwaiti dinar.

What this means for you. Confirm the currency your commercetools project trades in. If it uses two decimal places, amounts transfer correctly. If it uses any other number of decimal places, validate every monetary figure in a staging environment before relying on this integration in production, and expect to correct the affected mapping formulas. Subscribers or their MiSP who need currency-aware conversion should raise a feature request with iPaaS.com Support at support@ipaas.com.

At the time this documentation was written, orders and customers are brought into iPaaS.com by polling. The integration periodically asks commercetools which records have changed since its previous check and captures those records. There is no event-driven or webhook-based intake path from commercetools, and there is no commercetools event a subscriber can subscribe to in order to speed this up. Records therefore appear in iPaaS.com after a poll runs or after a Manual Sync, not at the moment they are created in the storefront.

Transfers in the opposite direction — the catalogue, location and inventory collections that write to commercetools — do have an automatic path, driven by the iPaaS.com outbound subscriptions configured under Outbound Data Flows. Where those subscriptions are not enabled, Manual Sync is the only transfer path for those collections.

What this means for you. Plan for a delay between an order being placed in commercetools and its arrival in iPaaS.com, and size that delay by setting the polling interval on your subscription. Use Manual Sync when you need a specific order or customer immediately, or to backfill history. For the outbound catalogue collections, confirm during installation that the relevant subscriptions are enabled under Outbound Data Flows, otherwise nothing transfers without a manual action.

At the time this documentation was written, each customer poll returns only a limited page of the customers changed since the previous check, and the integration then advances its last-checked marker past the whole window regardless of how many customers that page contained. Any customer changed within that window but not included in the returned page is not picked up on a later cycle — it is skipped, and no error is raised to indicate that it was. This is data loss, not a delay.

What this means for you. Manual Sync is the only recovery: re-sync the affected customer by its commercetools customer identifier to bring it across. Subscribers whose storefront produces more customer changes between two poll cycles than a single page can carry should shorten the polling interval so that fewer customers change within one window, confirm after each cycle that every expected customer has arrived, and validate this against their expected change volumes in a staging environment before relying on polling alone in production. Subscribers or their MiSP who need guaranteed capture of high-volume customer change should raise a feature request with iPaaS.com Support at support@ipaas.com.

At the time this documentation was written, three outbound collections rebuild their update instructions from the mapped values without checking whether a value is present. Where a field is not mapped, or where the mapped value resolves to nothing, the existing value in commercetools is overwritten with an empty value on every update. The affected collections and fields are:

The other outbound collections do not behave this way. Add/Update commercetools Product Category FROM iPaaS.com and the four inventory collections check for a value before building an update instruction, so an unmapped field on those collections leaves the commercetools value untouched. Do not assume the risk applies where it does not.

What this means for you. On the three collections listed above, map every field you want commercetools to keep — including fields you do not intend to change. Where the iPaaS.com record has no value to supply but the commercetools value must be preserved, use a formula referencing the existing commercetools value, for example DestinationValue.name or DestinationValue.description, so the current value is written back rather than cleared. Content maintained only in the commercetools Merchant Center on these fields will not survive an update from iPaaS.com unless it is protected in this way.

At the time this documentation was written, this integration does not delete records. Deletion is outside its scope for every entity in both directions: customers, customer addresses, orders, order line items, order taxes, order addresses, payments, products, product variants, variant option values, product attribute definitions, categories, locations and inventory entries. A record removed in one system remains in the other. A delete request submitted against any collection fails with a generic message that does not name the entity involved and does not indicate that deletion is out of scope.

What this means for you. Perform deletions directly in the system that owns the record — in the commercetools Merchant Center for commercetools data, and in iPaaS.com for iPaaS.com data — and perform them in both systems where the record must disappear from both. Do not build a workflow that expects a deletion to propagate. Subscribers or their MiSP who need deletion to flow between systems should raise a feature request with iPaaS.com Support at support@ipaas.com.

At the time this documentation was written, this integration does not offer an initialization run. There is no bulk first-load that sweeps an existing commercetools project into iPaaS.com, or an existing iPaaS.com catalogue into commercetools, ahead of normal operation. Every record arrives through the same route as ongoing changes: a poll, an outbound subscription, or a Manual Sync.

What this means for you. Plan your cutover around Manual Sync rather than around an initialization step. For a large historical backfill, use the documented bulk sync using Postman approach, which drives Manual Sync repeatedly from a prepared list of identifiers. Allow time for this in the implementation plan; it is the mechanism that replaces an initialization run.

At the time this documentation was written, no collision handling or duplicate detection is implemented for any collection in this integration. The integration recognises a record as already transferred only through the link it saved when it transferred that record itself. A commercetools customer, product, variant, category, channel or inventory entry that already existed — created by hand in the Merchant Center, imported by another tool, or created by an earlier integration — is not detected and is not reused. Where two collections or two systems write the same record, the later write wins; there is no merge, no conflict prompt and no selectable collision-handling method.

What this means for you. Start from a clean commercetools project where you can, or accept that pre-existing records will be duplicated rather than matched. Where a pre-existing commercetools record must be reused, link it manually before the first transfer. Where the same record can be written from two places, decide which one owns it and disable the other. Subscribers or their MiSP who need collision handling should raise a feature request with iPaaS.com Support at support@ipaas.com.

At the time this documentation was written, this integration does not transfer a record's dependencies for it. Where a record refers to another record, the referenced record must already exist in commercetools, and the integration enforces this by rejecting the transfer rather than by fetching the dependency. The ordering requirements are:

What this means for you. Sequence your initial load: categories from the top of the tree downwards, then locations, then product types and attribute definitions, then products, then variants and options, then inventory. Where a transfer is rejected for a missing dependency, transfer the dependency and re-run the record with Manual Sync. Do not expect a failed record to retry itself once the dependency arrives.

At the time this documentation was written, this integration performs no retry or rescheduling of its own. Where commercetools is temporarily unavailable when a transfer runs — a platform outage, a maintenance window, or a transient network failure between iPaaS.com and commercetools — the transfer fails outright. The record is not queued, is not picked up again on a later cycle, and is not re-attempted when commercetools becomes reachable again. This applies in both directions and to every collection.

The failure is, however, visible and recoverable. Every such failure is written to Dashboard / Integration Monitoring / Error Logs, and the record is brought across by re-running it once commercetools is available again:

This is the important contrast with section 5. A customer skipped by a poll cycle is lost silently — nothing is written to the Error Logs, and there is no signal that a record was missed. A transfer that fails because commercetools was unreachable is the opposite: it is loud, it names the record, and re-running it recovers it in full. Do not treat the two failure classes as the same.

What this means for you. Treat Dashboard / Integration Monitoring / Error Logs as the authoritative record of what failed, and check it after any period in which commercetools was unavailable. Build a re-run step into your operating procedure rather than assuming a failed transfer will resolve itself, and re-run through the parent record where the collection is a child collection. Where a large volume of records failed during an outage, drive the re-runs from a prepared list of identifiers using the bulk sync using Postman approach rather than one at a time.

At the time this documentation was written, the connection test on the commercetools connection reports success whenever it is run. It does not verify that the supplied credentials can obtain a token, and it does not verify that the commercetools project is reachable. A connection carrying an incorrect Client_Id, an incorrect Client_Secret, an incorrect Scope, or a project in an unsupported region all pass the test identically. The problem surfaces later, as an authorization failure on the first real transfer.

What this means for you. Do not treat a passing connection test as evidence that the connection works. Validate the connection by running a single Manual Sync of a known record and confirming the result under Dashboard / Integration Monitoring / Error Logs. Treat the first successful transfer, not the connection test, as the point at which credentials are confirmed. The credential set is described in commercetools Connections and Settings and the setup sequence in commercetools Installation Instructions.

At the time this documentation was written, every mapping collection in this integration is one-directional, and the two directions cover different entities. Orders, order line items, order taxes, order addresses, order payments, customers and customer addresses move from commercetools into iPaaS.com and are never written back. Products, product variants, variant options, attribute definitions, categories, locations and inventory move from iPaaS.com into commercetools and are never read back. There is no inbound flow that brings a commercetools product, variant, category, channel, attribute definition, option value or stock level into iPaaS.com, and no outbound flow that writes an order, order line, tax record, order address or payment into commercetools.

A correction made to an iPaaS.com order or customer stays in iPaaS.com. A correction made to a commercetools product or category stays in commercetools, subject to section 6.

What this means for you. Decide which system owns each kind of data and edit it there. Catalogue, stock and location data is owned by iPaaS.com; order, payment and shopper data is owned by commercetools. Where a value must exist in both systems and can change in either, expect to reconcile it manually. Where a round trip is needed, both directions must be configured as separate collections, and only the pairs listed above exist.

At the time this documentation was written, this integration has no custom-field implementation. commercetools custom fields on the customer record, on customer addresses, on orders, on order line items, on inventory entries and on order addresses are neither read nor written, in either direction. The same applies to commercetools stores, customer groups, locale and authentication mode on the customer record.

What this means for you. Any data your business keeps in a commercetools custom field will not reach iPaaS.com through this integration, and any iPaaS.com value you want stored in a commercetools custom field will not get there. Plan to carry that data another way, or keep it in the system that owns it. Subscribers or their MiSP who need custom-field support should raise a feature request with iPaaS.com Support at support@ipaas.com.

At the time this documentation was written, Add/Update commercetools Location FROM iPaaS.com is an add-only collection. It writes a commercetools channel the first time a Location transfers and does not update it afterwards, so a Location renamed or re-described in iPaaS.com keeps its original values in commercetools. The channel is created carrying its key, name and description only. commercetools channel roles — including the inventory-supply role that marks a channel as usable as a warehouse — are not set, and channel addresses and geographic coordinates are not written.

A commercetools channel that carries no inventory-supply role is not a supply channel, so a channel this integration creates may not accept inventory entries until the role is assigned in commercetools.

The key is also a hard requirement: a Location with no key value cannot be transferred at all, because the transfer fails rather than creating a channel without a key. The shipped mappings derive the key from the location name, so a Location carrying no name has no key to derive.

What this means for you. Give every iPaaS.com Location you intend to transfer a value that the key mapping can resolve, because a Location with no key does not transfer. After the first Location transfer, open each new channel in the commercetools Merchant Center and assign the inventory-supply role before you transfer any inventory against it. Make subsequent changes to a location — its name, description, address or coordinates — directly in commercetools, because a later iPaaS.com change will not reach it. Subscribers or their MiSP who need location updates or automatic role assignment should raise a feature request with iPaaS.com Support at support@ipaas.com.

At the time this documentation was written, all four inventory collections depend on a supply channel resolved from the mapped Location, and that dependency is stricter than it appears. A supply location that has not been transferred to commercetools stops the inventory transfer. An inventory entry that exists in commercetools without a supply channel — created by hand, or created before a Location was mapped — cannot be updated by this integration at any point afterwards; it is permanently beyond reach and must be corrected in commercetools directly. Moving an existing inventory entry between supply channels may also be rejected even where creating an entry against the same channel succeeds.

What this means for you. Keep Location mapped on every inventory collection you enable, and make sure it always resolves to a location that has already reached commercetools. Transfer locations first, assign the inventory-supply role as described in section 15, and only then transfer inventory. Validate a channel move in a staging project before performing one in production. Where an inventory entry has already been created without a channel, correct it in the commercetools Merchant Center — re-running it through the integration will not fix it.

At the time this documentation was written, inventory quantity handling differs between the create path and the update path, and between the child and standalone collections:

What this means for you. Use Quantity as the value that moves stock. Maintain reservations, restock lead time, expected delivery dates and cart quantity limits directly in commercetools, because this integration neither writes them nor clears them. Map MinQuantity deliberately rather than leaving it out, because omitting it writes zero rather than nothing. Create every inventory entry through Add/Update commercetools Product Inventory FROM iPaaS.com or Add/Update commercetools Product Variant Inventory FROM iPaaS.com before relying on the standalone update collections. Confirm in a staging project what commercetools stores for available quantity before relying on it in production.

At the time this documentation was written, the child inventory collection and the standalone inventory update collection respond to the same iPaaS.com outbound subscriptions. This is true for both the product pair and the variant pair. Where both collections in a pair are enabled, each iPaaS.com inventory change is processed twice, from two different mapping configurations.

What this means for you. Enable one collection from each pair, not both. Use the child collection when inventory entries need to be created as well as updated, and the standalone collection only where entries already exist and you want updates isolated from the parent product transfer. Review which collections are enabled on your subscription before go-live.

At the time this documentation was written, activity and error records produced by inventory updates are filed in the iPaaS.com Activity Tracker under Product Category rather than under an inventory heading. The transfer itself behaves normally; only the category the activity is recorded against is affected. A subscriber looking for inventory activity where they expect it will not find it, and no message indicates that it has been filed elsewhere.

What this means for you. When you are tracing an inventory transfer, look under Product Category in the Activity Tracker as well as under the inventory collections. Use Dashboard / Integration Monitoring / Error Logs as the primary place to confirm whether an inventory transfer succeeded or failed, rather than the Activity Tracker.

At the time this documentation was written, this integration does not create commercetools product types, and it does not create categories on demand during a product transfer. Product types must be created in the commercetools Merchant Center before the first product transfer, and categories must be transferred through Add/Update commercetools Product Category FROM iPaaS.com before a product is assigned to them. Attribute definitions are created by Add/Update commercetools Product Attribute FROM iPaaS.com, but only as part of a parent Product transfer — there is no independent automatic path for them.

What this means for you. Build the commercetools product types by hand as part of implementation, and record their identifiers, because the shipped product-type lookup translation must be repointed at them (see the productType_id entry in the placeholder checklist below). Transfer your category tree before your products. Do not expect a product transfer to conjure a missing product type or category into existence.

At the time this documentation was written, several commercetools content areas are outside the scope of the outbound catalogue collections. Product images, product assets, search keywords and product metadata fields are not written. Variant images and assets are not written. Category assets, meta titles, meta descriptions and meta keywords are not written. Multiple prices per variant are not written — a single price is written per variant, and commercetools price scopes such as per-channel or per-customer-group pricing are not used. Attribute labels, input tips and option labels are written in English only.

What this means for you. Maintain product and category imagery, search and merchandising metadata directly in the commercetools Merchant Center; the integration will not overwrite it, and it will not supply it either. Where a variant needs more than one price, or a price scoped to a channel or customer group, add it in commercetools after the transfer. Subscribers or their MiSP who need media or metadata publishing should raise a feature request with iPaaS.com Support at support@ipaas.com.

At the time this documentation was written, a product carrying more than one hundred variants is stopped by this integration before the transfer is attempted, with a message stating that commercetools does not allow more than one hundred variants. One hundred is a genuine commercetools platform limit, but commercetools documents it as configurable — "This limit can be increased per project after we review the performance impact" (https://docs.commercetools.com/api/limits, retrieved 2026-07-20). The integration's threshold is fixed at one hundred regardless of the limit configured on the project, so a subscriber whose project limit has been raised is still stopped at one hundred, and the message they receive describes a platform restriction that no longer applies to their project.

What this means for you. Keep products at or below one hundred variants for transfer purposes, and split larger products where you can. If you have had your commercetools project limit raised and are still being stopped, the block is coming from the integration rather than from commercetools — contact iPaaS.com Support at support@ipaas.com rather than commercetools support, and raise a feature request for a project-aware limit.

At the time this documentation was written, two variant behaviors are derived rather than mapped. An unmapped or empty price produces a variant priced at zero rather than a variant with no price. The variant key is derived from the stock keeping unit with spaces removed, so two stock keeping units that differ only by spacing produce the same variant key and collide.

What this means for you. Map a price on every variant you transfer, and treat an unmapped price as a data-quality problem rather than as an omission — a zero price is a publishable price in commercetools. Review your stock keeping units for pairs that differ only in spacing before the first variant transfer, and normalise them in iPaaS.com so that each produces a distinct variant key.

At the time this documentation was written, every attribute definition Add/Update commercetools Product Attribute FROM iPaaS.com creates carries the same six settings: it is a keyed-option list, not required, unconstrained across variants, multi-line and searchable. These settings are the same for every attribute and are not driven by the iPaaS.com record. An existing definition is never reshaped by a later transfer, so its type, constraint, presentation and searchability settings do not change once created — and changing the fixed values in the collection affects only definitions created afterwards. Attribute definitions apply to the whole product type, not only to the product whose transfer created them.

What this means for you. Where an attribute needs different settings — a required attribute, a single-line attribute, a non-searchable attribute, or a type other than a keyed-option list — create it directly in commercetools before the first product transfer, so that this collection finds it already defined and leaves it alone. Remember that adding an attribute through this collection changes the product type for every product that uses it, not only the product being transferred.

At the time this documentation was written, variant option values are matched to their commercetools attribute by attribute name alone. Renaming an option in iPaaS.com therefore produces an additional attribute on the variant rather than replacing the existing one. On a newly added variant the stored value and the displayed label are always the same text — separate option codes and display labels are not supported. A new variant carrying no option values fails, and takes the parent product transfer down with it.

What this means for you. Treat option names as stable once transferred; rename them in commercetools directly rather than in iPaaS.com, and clean up any duplicate attribute left behind by a rename. Make sure every iPaaS.com Product Variant intended for transfer carries at least one option before you run the parent product, because a variant with none stops the whole product.

At the time this documentation was written, Add/Update commercetools Product Category FROM iPaaS.com derives its key and slug from the category name, which introduces several constraints. A long category name or a deeply nested taxonomy can produce a derived value that commercetools rejects. A category name shorter than three characters can fail on update, because of how the update path derives its internal comparison value. A category updated with no description value fails, because the update path compares the incoming description against the stored one. In addition, the shipped description mapping carries the category name rather than a description, so categories arrive in commercetools with the name repeated as the description until that mapping is repointed.

What this means for you. Review your category names before the first transfer: give every category a name of at least three characters, keep names short enough that a derived key and slug stay within a reasonable length, and validate a deeply nested branch in a staging project before relying on it in production. Give every category a description value. Repoint the description mapping at a real description field during implementation if you do not want the name duplicated.

At the time this documentation was written, the tax category lookup used by Add/Update commercetools Product FROM iPaaS.com returns an empty reference rather than nothing when the tax category name it is given matches no tax category in the commercetools project. That empty reference passes the transfer's own validation and is sent to commercetools, so the resulting failure comes back describing an invalid tax category reference rather than pointing at the mapping that produced it. No message identifies the tax category mapping as the cause.

What this means for you. If a product transfer fails with a tax-category complaint, check the tax category mapping first — it is the most likely cause and it will not name itself. Confirm before go-live that the tax category name the mapping resolves is a name that exists in your commercetools project. This is the hardest of the shipped placeholder values to diagnose if it is left unreplaced; see the tax category entry in the placeholder checklist below.

At the time this documentation was written, orders arrive in iPaaS.com as an order-level summary with its line items, rather than as a full reproduction of the commercetools order. Specifically: the Type value passes a raw commercetools value into a constrained iPaaS.com field with no lookup translation in front of it, so a value outside the iPaaS.com domain is rejected at intake. The order-state lookup translation does not cover the commercetools Confirmed order state. The discount total sums the discounts recorded on the order's line items, covering both item-level and cart-level discounts, but discounts recorded only at the order level and not on any line are not included. Line-level discount detail is not itemised. Gift card lines, including the gift card identifier those lines require, are not carried. Custom line items — commercetools order lines not backed by a catalogue product — are not covered. Line-level shipping addresses are not mapped.

What this means for you. Before go-live, compare the commercetools order Type values your storefront produces against the values the iPaaS.com field accepts, and add a lookup translation if they differ. Add a translation row for the Confirmed order state if your workflow uses it. If your storefront issues gift cards or uses custom line items, expect those lines to be absent or incomplete in iPaaS.com and plan to handle them separately. Reconcile discount totals against commercetools during the first weeks of operation.

At the time this documentation was written, one order-level tax record is produced per order. The individual tax portions commercetools records per jurisdiction are not transferred as separate rows, and the tax percent is taken from the first tax portion on the order only — on a multi-jurisdiction order it does not describe the full tax that was charged. The tax amount and the original tax amount are populated from the same source, so the two can never differ and a transaction carries no record of a tax figure having been adjusted. An order for which commercetools calculated no tax still produces a tax record on the transaction, with no amount set. The integration transfers the tax commercetools has already calculated; it does not calculate, verify or recalculate tax.

What this means for you. Do not use the transferred tax percent for jurisdiction-level tax reporting on multi-jurisdiction orders — use commercetools as the source for that. Downstream systems that treat the presence of a tax record as evidence that tax was charged should be checked against this behavior, because a zero-tax order still produces one. Where per-jurisdiction detail is required in iPaaS.com, raise a feature request with iPaaS.com Support at support@ipaas.com.

At the time this documentation was written, no comparison is made between an incoming order address and the address already on the iPaaS.com transaction. Re-transferring the same order rewrites both the shipping and the billing address unconditionally. An order with no billing address in commercetools still produces a billing address record on the transaction, carrying the primary billing flag but no address content. Addresses are written exactly as commercetools recorded them — no verification, correction or postal standardization is performed, and no fallback to the shipping address occurs when a billing address is absent. Only the order-level shipping address is carried; per-item shipping destinations are not. No phone number, second address line or address type is carried on the billing address.

Separately, the shipping method name has no translation step in front of it. iPaaS.com documents this value as needing to match the name of a configured shipping method, so a commercetools shipping method name with no iPaaS.com counterpart is the most likely source of trouble on the shipping address collection.

What this means for you. Do not hand-correct an order address in iPaaS.com if that order may transfer again — the correction will be overwritten. Downstream systems that assume a flagged billing address is a populated billing address should be checked against this behavior. Pre-configure the matching iPaaS.com shipping methods before go-live, and validate an unmatched shipping method name in a staging environment before relying on this path in production. Add mappings for phone, second address line or address type if a downstream system needs them.

At the time this documentation was written, every order line arrives in iPaaS.com with a status of Pending, regardless of the parent order's status, and typed Product, including lines that represent gift cards. Only the English (United States) line item name is transferred. A commercetools line item whose variant carries no stock keeping unit is rejected, because a line typed Product must resolve to an existing product or variant in iPaaS.com.

What this means for you. Do not use the line status as a fulfilment signal — read the order status instead. Confirm that every product and variant your storefront sells carries a stock keeping unit in commercetools, because lines without one will not transfer. If you sell in more than one locale, expect the English (United States) name on every line.

At the time this documentation was written, the status recorded on every payment transferred into iPaaS.com is fixed at Authorized. It does not track the commercetools payment state, so a payment that is pending, failed or in a credit-owed state in commercetools still arrives in iPaaS.com as authorized, and no message indicates the substitution. Payment records also arrive only when their parent order is retrieved, so a payment added to an order in commercetools after that order has already transferred does not reach iPaaS.com until the order transfers again. Payment transaction detail below the payment record itself — individual authorizations, captures, refunds and their states — is not transferred, and there is no de-duplication guard specific to payments, so repeated transfers of the same order re-present the same payment records.

What this means for you. Do not reconcile payments using the iPaaS.com payment status — it is uniform and carries no information about whether the payment actually succeeded. Use commercetools as the source of truth for payment state, and re-transfer an order after a payment is added if you need that payment in iPaaS.com. Subscribers or their MiSP who need real payment state carried across should raise a feature request with iPaaS.com Support at support@ipaas.com.

At the time this documentation was written, the order child collections use mapping filters to decide which candidate records they act on, and a record the filter does not select is skipped silently. No error is written, and nothing in the Activity Tracker or the Error Logs indicates that a record was considered and passed over. The order shipping address, billing address and tax collections act only on the order-level candidate; the order payment collection acts only on the payment-level candidates.

One collection is affected more completely. Add/Update commercetools Order Payment Placeholder TO iPaaS.com ships with a filter that can never select a record, so the collection is inactive as delivered and produces nothing. If a subscriber enables it by changing that filter, it produces one identical stand-in payment record per order, varying only in amount — the method, description and status never vary. Enabling it alongside Add/Update commercetools Order Payment TO iPaaS.com on an order that carries real payments gives the transaction both, and overstates the payment total.

What this means for you. If an order child record you expected does not appear, check the collection's mapping filter — the absence of an error does not mean the record was rejected, it may simply not have been selected. Leave the payment placeholder collection as shipped unless you have a specific need for stand-in payment records, and never enable it at the same time as the real payment collection. If you do enable it, note the prerequisite recorded in the placeholder checklist below.

At the time this documentation was written, customers are identified by email address across the order and customer intake collections. Orders link to customers by email address only, so two commercetools customers sharing an email address cannot be distinguished. On customer intake, the commercetools email address is captured directly with no de-duplication step: if two commercetools customers share an email address, the second one to transfer fails to create in iPaaS.com because the address is already in use, and that failure appears under Dashboard / Integration Monitoring / Error Logs. Only the five mapped customer values — customer number, email address, first name, last name and company — are captured; any other commercetools customer detail requires an additional mapping.

What this means for you. Enforce unique email addresses in commercetools before you begin transferring customers, and resolve any existing duplicates first. Where a shared address is unavoidable, expect the second customer to fail and expect orders from both to attach to the same iPaaS.com customer. Add mappings for any customer field beyond the five listed above that your downstream systems need.

At the time this documentation was written, address handling carries several constraints in both directions.

Inbound, from commercetools into iPaaS.com: commercetools stores the street name and the street number as two separate values, and only the street name is mapped to Address1. In markets where the street number is entered in its own field, iPaaS.com addresses arrive without a house or building number, which affects shipping and address validation downstream. Only one address line is captured, though iPaaS.com supports more. The commercetools street number, additional street information, building, apartment, PO box, department, address key and external identifier, and the address-level email, phone, mobile and fax values are not captured, nor is address type or the primary billing and primary shipping designation. An address a shopper deletes in commercetools is not removed from the previously captured iPaaS.com address.

Outbound, from iPaaS.com into commercetools: the shipped Country translation covers the United States only, so address data for any other country requires additional translation rows before it can be transferred. Addresses move only with their parent Customer — there is no address-only outbound flow — and a Customer with no addresses cannot be transferred at all, because the parent transfer fails rather than writing a customer without address data. Addresses on the same customer are paired by street name, so two addresses sharing a street name can have their links crossed. Default shipping and billing address designation is not set.

What this means for you. Add the street number to the Address1 mapping before go-live if your markets record it separately. Add a translation row for every country you ship to or bill in, before the first Customer transfer, because only the United States is covered as shipped. Make sure every iPaaS.com Customer you intend to transfer carries at least one address. Verify address links after the first transfer where a customer has two addresses on the same street. Set default shipping and billing designations in the commercetools Merchant Center.

At the time this documentation was written, this integration reads and writes English content only. Product names and descriptions are written to the English locale, attribute labels and input tips are written in English, option labels are written in English, and on the inbound side only the English (United States) line item name is transferred. Other commercetools locales on the same record are neither read nor written.

What this means for you. Maintain non-English locale content directly in the commercetools Merchant Center. Note that on the product collection this interacts with section 6: the English name and description fields are cleared when unmapped, while other locales are left alone. Subscribers or their MiSP who need multi-locale publishing should raise a feature request with iPaaS.com Support at support@ipaas.com.

At the time this documentation was written, commercetools enforces limits on how many of each resource a project may hold, and this integration does not raise or work around them. commercetools publishes these at https://docs.commercetools.com/api/limits (retrieved 2026-07-20).

The quotas most relevant to this integration, and whether each can be raised:

The distinction matters: for every configurable quota above you can ask commercetools to review an increase, but attribute groups is a hard limit, so a project that reaches 100 must be restructured rather than extended.

Two further constraints apply to the 100-variant figure. It is configurable at the platform, but the integration enforces its own fixed guard of 100 regardless of your project's raised limit — described in section 22 — so raising the platform limit alone will not let more variants through. And the integration does not automatically reschedule or resume a transfer that is refused for rate or quota reasons.

What this means for you. Size your catalogue, category tree and customer base against the published commercetools quotas before you plan a bulk load, and consult https://docs.commercetools.com/api/limits for the current figures, since they change. Where a configurable quota is the constraint, request an increase from commercetools directly — but do not plan around raising the attribute-group limit, which is fixed. Stagger large transfers rather than running several at once, and re-run refused records with Manual Sync; the integration will not retry them for you.

At the time this documentation was written, commercetools bounds the shape of an individual query request. A limit parameter accepts a value between 0 and 500, and the default on most query endpoints is 20; offset defines the number of elements skipped rather than a page number, defaults to 0, and has a maximum of 10,000 (https://docs.commercetools.com/api/general-concepts, retrieved 2026-07-20). These bounds apply to every read this integration performs against commercetools, and they interact with the polling behavior described in section 5.

What this means for you. These maximums are the reason a single poll or a single lookup returns a bounded set of records rather than everything that matches. Where you need to move more records than a single request can carry, plan the work as a series of Manual Syncs — see the bulk sync using Postman approach in section 8 — rather than expecting one transfer to sweep an unbounded volume.

The default mapping set ships with six example values that make the collections functional out of the box. They are expected configuration steps, not faults — each one is an intentional working default that a subscriber is expected to replace with their own value during implementation. Every one of them must be reviewed before go-live.

The six entries, grouped by the collection they belong to:

Add/Update commercetools Customer FROM iPaaS.com

Add/Update commercetools Product FROM iPaaS.com

Add/Update commercetools Product Attribute FROM iPaaS.com

Add/Update commercetools Order Payment Placeholder TO iPaaS.com

This article covers thirty-eight known limitations of the commercetools integration, together with the six placeholder values that must be replaced before go-live. For the detailed technical documentation of any individual data flow — the fields carried, the mapping filters applied, the requiredness of each value, and the out-of-scope items specific to that flow — refer to the mapping collection description for that collection, available from the mapping page of your iPaaS.com subscription. For the endpoints the integration calls, see commercetools API Endpoints; for setup, see commercetools Installation Instructions; for the failures that do produce a message, see commercetools Error Messages.