Use the Error Logs rather than the activity feed as your source of truth. In the current release, some failed calls to commercetools are recorded in the Activity Tracker with a success status and a "Complete" result, so a transfer that failed can still appear to have succeeded in the activity feed. The Error Logs record the failure correctly. Two entries in this article are the exception — Network Or Certificate Failure and iPaaS.com Lookup Failed quote wording that is written to the Activity Tracker rather than to the Error Logs, and each says so. For every other entry, search the Error Logs.

Some error messages quoted below are inaccurate or misspelled. They are reproduced here exactly as they appear so that you can search for them, and each entry explains in plain language what actually went wrong. Do not read the message text itself as a reliable description of the problem.

Connection and Authentication

All Data Transfer Flows

Product FROM iPaaS.com

Product Variant FROM iPaaS.com

Product Category FROM iPaaS.com

Product Inventory FROM iPaaS.com

Description: The integration attempted to obtain an access token from commercetools and found no client ID value. This occurs when the connection is first established, and again whenever a stored token has to be replaced. The message is misleading and cannot be corrected without a product update. The client ID is not read from a "SystemTypeVersion CustomField" — it is read from the Client_Id subscription setting described in Connections and Settings. That setting is the only place to look.

Resolution: Open your subscription's settings and confirm that Client_Id is present and has no leading or trailing spaces. The value comes from the API Client you created in the commercetools Merchant Center; if you no longer have it, create a new API Client and re-enter all four connection values. See Connections and Settings for the full list. If Client_Id is populated and the error persists, contact iPaaS.com Support at support@ipaas.com.

Description: The same authorization step found no client secret value. As with the previous error, the reference to "CustomFields for this SystemTypeVersion" is inaccurate — the value is read from the Client_Secret subscription setting documented in Connections and Settings. Client secrets are shown only once when an API Client is created in the commercetools Merchant Center, so this error most often means the secret was never captured or was pasted incompletely.

Resolution: Confirm that Client_Secret is populated in your subscription settings. Because commercetools does not display an existing secret a second time, you cannot recover the original value — create a new API Client in the Merchant Center and re-enter Client_Id, Client_Secret, Scope, and API Url together, as described in Connections and Settings. If the setting is populated and the error persists, contact iPaaS.com Support at support@ipaas.com.

Description: The integration sent your credentials to the commercetools authorization service and did not get a usable access token back. The wording is inaccurate and cannot be corrected without a product update — this integration uses a direct client credentials exchange and there is no "temporary code" involved anywhere. The real meaning is simply that commercetools declined the credentials. The usual causes are an incorrect Client_Secret, a Scope value that does not match the project key in your API Url, an API Client that has been deleted or has expired in the Merchant Center, or a commercetools project hosted outside the region this release supports. Region support is covered in API Endpoints and in Known Limitations.

Resolution: Check, in order: that Scope contains the same project key that appears in API Url; that the API Client still exists and is active in the commercetools Merchant Center; and that the scopes granted to that API Client cover the collections you are transferring. Re-entering Client_Secret from a freshly created API Client resolves most occurrences. Confirm your project's region is supported before troubleshooting further — see API Endpoints. If all four values are correct and current, contact iPaaS.com Support at support@ipaas.com.

Description: commercetools rejected an authenticated request with an HTTP 401. In the current release the connection test always reports success regardless of whether the credentials work, so a wrong or expired credential does not surface when you test the connection — it surfaces here, on the first real transfer. {action} names the internal operation being attempted and {response body} is the raw text commercetools returned. The name CommerceTool in the message is the integration's internal application name; the product is commercetools. Both are cosmetic and cannot be changed from the user interface.

Resolution: Do not rely on a passing connection test as evidence that your credentials are valid. Re-verify Client_Id, Client_Secret, Scope, and API Url against the API Client in your commercetools Merchant Center, per Connections and Settings. If the API Client's granted scopes do not include the resource being written — for example manage_products for a product transfer — commercetools returns 401 even though the credentials themselves are valid, so check the granted scopes as well. If the credentials and scopes are confirmed correct, contact iPaaS.com Support at support@ipaas.com.

Description: commercetools returned a non-success HTTP status for a create, update, or read. This is the most common error in the integration and is a wrapper around whatever commercetools itself reported — the useful detail is in the {response body} portion, which contains the raw response text. {status} is the HTTP status name. A 400 usually means the record failed commercetools validation (a required field missing, a value outside an allowed set, or a reference to a record that does not exist in your project). A 409 means another process changed the same record between the moment the integration read it and the moment it wrote it back. A 404 on an update means the destination record no longer exists. A 429 means you exceeded the request rate your project allows.

Resolution: Read the response body in the Error Logs entry — commercetools names the offending field in its own error text. Correct the source record or the mapping that produces that field, then re-run the transfer. For a 409, re-run the transfer; the integration reads the current record version each time it writes, so a retry normally succeeds once the competing change has settled. For a 429, transfers are not automatically rescheduled or resumed by this integration — stagger large jobs, avoid running several intensive transfers at the same time, and re-run the affected records. commercetools publishes its request limits at https://docs.commercetools.com/api/limits (retrieved 2026-07-20). If the response body is empty or names no field, contact iPaaS.com Support at support@ipaas.com with the full Error Logs entry.

Description: The request never reached commercetools, or the response could not be read. This covers name resolution failures, TLS or certificate negotiation failures, and connection timeouts. This particular wording is written to the Activity Tracker rather than to the Error Logs — it is one of two messages in this article that you will find in the activity feed rather than in the Error Logs. The Error Logs entry for the same failure carries the underlying network or certificate message instead, which is the text that names the actual cause. Search both places. The misspelling of "Received" is present in the shipped message and is reproduced here so you can search for it. {action} names the operation in subscriber-facing terms, for example CREATE Categroy — that action label is itself misspelled in the shipped code for the Product Category flow. The underlying network message is also recorded on the technical log, under a label ending in RestReqeuest (also misspelled in the shipped code).

Resolution: Confirm that the host in your API Url setting is reachable and spelled correctly, including its region component — see Connections and Settings and API Endpoints. Re-run the transfer, since transient network failures do not repeat. If the failure is consistent, or the technical log names a certificate or TLS problem, contact iPaaS.com Support at support@ipaas.com.

Description: A delete was requested for a commercetools record. Delete is not supported by this integration for any entity, in either direction. The message you receive is the generic default supplied by the runtime — it names no entity, no collection, and gives no indication that delete is simply an unsupported operation, which makes this the hardest error in the integration to recognise from its text alone. If you see this message and no other explanation, a delete is the most likely cause. The same generic text also appears for a small number of unfinished read paths on the Order, Payment, and Tax Category records.

Resolution: Remove any configuration that asks the integration to delete a commercetools record, including delete-triggered outbound data flows. Records must be removed directly in the commercetools Merchant Center. See Known Limitations for the full statement of what is and is not supported. If you receive this message and no delete was configured anywhere in your subscription, contact iPaaS.com Support at support@ipaas.com with the Error Logs entry.

Description: The transfer reached the point of writing to commercetools but the record to be written had not been built. This normally means the mapping produced no usable record — for example, every mapped field evaluated to empty, or a Dynamic Formula returned nothing. {collection} names the mapping collection involved. The same wording appears with the operation name changed for other stages of a transfer: Call to CollectionUpdate…, Call to CollectionGet…, Call to CollectionDelete…, Call to PollRequest…, and Call to GetPrimaryId…, each ending in sourceObject is null or sourceObject could not be created.

Resolution: Open the mapping collection named in the message and confirm that its required fields are mapped and that the source records actually carry values for them. Test any Dynamic Formula in the mapping to confirm it returns a value for the record that failed. If the mapping is complete and populated source records still produce this error, contact iPaaS.com Support at support@ipaas.com.

Description: The record handed to the integration was not the type the named collection expects. This normally indicates a mapping collection configured against the wrong record type, or a child collection linked to the wrong parent. The same wording appears for the other transfer stages, ending in sourceObject type= — Call to CollectionUpdate…, Call to CollectionGet…, Call to SetPrimaryId…, and Call to GetPrimaryId… No matching object.

Resolution: Review the mapping collection named in the message and confirm it is configured for the intended record type, and that any child collection is attached to the correct parent collection. If the configuration is correct, contact iPaaS.com Support at support@ipaas.com.

Description: A transfer was configured for a record type this integration does not implement. The integration supports a defined set of collections — customer, customer address, order and its child collections, product, product variant, product attribute, product category, product inventory, and location. A collection outside that set produces this error as soon as a transfer is attempted.

Resolution: Disable or remove the mapping collection named in the message. Consult Known Limitations for the definitive list of supported collections before configuring new transfers. If the collection named is one you expected to be supported, contact iPaaS.com Support at support@ipaas.com.

Description: The identifier used to match a record between iPaaS.com and commercetools was not in the expected format. This variant expects a whole number and received something else. Two related variants appear with ExpectedDataType = String with one separator and ExpectedDataType = String with two separator; those apply to composite identifiers built from two or three parts joined by a vertical bar, most commonly for product variants and inventory records. In every case {value} shows the identifier that was actually supplied, which is the fastest way to spot the problem.

Resolution: This is a data or mapping problem, not a product fault. Compare the value shown in PKValue against the format the message expects, then correct the mapping that produces the identifier. Composite identifiers must contain exactly the number of vertical-bar separators the message names, with no empty segments. Re-run the transfer once the mapping is corrected. If the value shown looks correct for the format named, contact iPaaS.com Support at support@ipaas.com.

Description: commercetools returned a record whose identifier could not be stored against the iPaaS.com record — usually because it was empty, or because a composite identifier arrived with a missing segment. It occurs after a successful write, while the two systems are being linked, which means the record may exist in commercetools without being linked back to iPaaS.com. The record name in the message is an internal one and may not exactly match the collection name you see in the user interface.

Resolution: Check whether the record was in fact created in the commercetools Merchant Center. If it was, re-run the transfer for that record so the link can be established; the integration matches on the identifier and will update rather than duplicate. If the same record fails repeatedly, or you find duplicates in commercetools, contact iPaaS.com Support at support@ipaas.com.

Description: A lookup against iPaaS.com failed. The integration queries iPaaS.com during a transfer to translate an iPaaS.com identifier into the corresponding commercetools identifier — this is how categories, locations, tax categories, and product types are resolved. The most common cause is that the referenced record has never been transferred to commercetools, so no link between the two systems exists yet. This wording, like the network failure message above, is written to the Activity Tracker rather than to the Error Logs — these two are the exception to the guidance at the top of this article, so search the activity feed for this string and the Error Logs for the underlying lookup message. The misspelling of "Received" and the internal component name in the message are present in the shipped text and are reproduced here so you can search for it.

Resolution: Identify the record being referenced and confirm it has already been transferred to commercetools successfully. Categories, locations, and product types must exist in commercetools before any record that references them can transfer. Transfer the referenced record first, then re-run the failed transfer. If the referenced record is confirmed present in commercetools and the lookup still fails, contact iPaaS.com Support at support@ipaas.com.

Description: The integration asked for the identifier of a record it had just written and the response type it received had no way to supply one. This is a product defect rather than a configuration problem — no subscriber action causes it and no mapping change avoids it.

Resolution: Contact iPaaS.com Support at support@ipaas.com with the Error Logs entry, including the collection and the record involved.

Description: The integration could not determine which iPaaS.com endpoint corresponds to the collection being transferred. Two closely related messages come from the same cause: Unable to determine table name for mapping collection type {collection} and Unhandled endpoint type: {endpoint}. A fourth, Unsupported parameter type: {type}, indicates a request could not be assembled. None of these are caused by anything a subscriber configures, and none can be resolved from the user interface.

Resolution: Contact iPaaS.com Support at support@ipaas.com with the Error Logs entry and the name of the mapping collection that was running.

Description: A product could not be written to commercetools because no product type was resolved for it. Every commercetools product must reference a product type, and this integration does not create one for you. It occurs on both creates and updates. The shipped default mapping resolves the product type through a Lookup Translation whose destination values are product type identifiers specific to your commercetools project — those shipped values are examples and must be replaced with your own before go-live. If the Lookup Translation has no entry matching the source product's category, or the entry still holds an example identifier that does not exist in your project, no product type is resolved and this error is raised. As with Variant Options Missing and Parent Product Not Identified below, the message is raised as an "operation is not implemented" style exception even though it is a validation failure — the operation is implemented, the input was incomplete.

Resolution: Open the Lookup Translation used by the productType_id mapping on this collection and confirm it has an entry for the source value on the failing product, and that the destination value is a product type identifier that genuinely exists in your commercetools project. Product type identifiers can be read from the commercetools Merchant Center. The placeholder values shipped with the default mappings are listed in Known Limitations — replace all of them before running production transfers. Once the Lookup Translation is corrected, re-run the transfer.

Description: The product being transferred has more than 100 variants, and the transfer was stopped before any data was sent. The message is not accurate for every subscriber. commercetools does document a 100-variant limit per product, but states that the limit "can be increased per project after we review the performance impact" (see https://docs.commercetools.com/api/limits, retrieved 2026-07-20) — it is configurable, not a fixed platform restriction. The integration's own check, however, is fixed at 100 and does not read your project's actual limit. If commercetools has already raised the limit for your project, your product is still blocked here, and the message will send you to commercetools for a limit you already have. Treat the number in this message as the integration's threshold, not as your project's.

Resolution: This check is an error filter on the Product FROM iPaaS.com mapping collection, which means it is a Dynamic Formula you can edit yourself in the iPaaS.com user interface. If commercetools has confirmed a higher variant limit for your project, edit the error filter on this collection to match the limit your project actually has, and correct the message text at the same time. If your project is on the standard 100-variant limit, either reduce the number of variants on the source product or split it into more than one product before re-running the transfer. Request a limit increase from commercetools support only after confirming your project has not already been granted one.

Description: A new variant was being added to a product and carried no attribute values. commercetools distinguishes variants of the same product by their attribute values, so a variant with none cannot be created. This applies only to variants being created; existing variants being updated are unaffected. Note that the message is raised as an "operation is not implemented" style exception even though it is a validation failure — the operation is implemented, the input was incomplete.

Resolution: Open the Product Variant FROM iPaaS.com mapping collection and confirm that at least one attribute is mapped and that the source variant carries a value for it. Variants that legitimately have no distinguishing attributes should not be transferred as separate variants. Re-run the transfer once the source data or the mapping is corrected.

Description: A product variant could not be created or updated because the parent product it belongs to was not identified. commercetools stores variants inside the product record, so the product must be known before a variant can be written. This normally means the parent product has not yet been transferred to commercetools, or the parent product transfer failed earlier in the same run and the variant was attempted anyway. As with the previous entry, this is a missing-input validation failure reported through an "operation is not implemented" style exception.

Resolution: Confirm the parent product transferred successfully to commercetools before the variant was attempted — check the Error Logs for a failure on the Product FROM iPaaS.com collection in the same run and resolve that first. Because the product must exist before any of its variants, transferring the product on its own and then re-running the variant transfer resolves most occurrences. If the parent product is confirmed present in commercetools and its variants still fail, contact iPaaS.com Support at support@ipaas.com.

Description: A category that has a parent category was transferred before its parent existed in commercetools. This integration does not transfer a record's dependencies automatically, so categories must reach commercetools in hierarchy order — parents before children. The check compares the parent named on the incoming category against the categories already linked between the two systems; if no link is found, the transfer is stopped. Top-level categories with no parent are not affected.

Resolution: Transfer the parent category first, then re-run the failing category. For a first-time load of a full category tree, transfer the tree one level at a time from the top down. This check is a filter on the Product Category FROM iPaaS.com mapping collection and is a Dynamic Formula you can view and edit in the iPaaS.com user interface — but the underlying requirement is real, so removing the check will not make the transfer succeed; it will only replace this clear message with a rejection from commercetools.

Description: commercetools rejected a category write. On this collection the most frequent causes are a category name, description, or slug that was not mapped or arrived empty, and a slug that duplicates one already used in the project — commercetools requires category slugs to be unique. The internal action name for this collection is misspelled as CREATE Categroy in the Activity Tracker; that is cosmetic and does not affect the transfer.

Resolution: Confirm that name, description, and slug are mapped on the Product Category FROM iPaaS.com collection and that the source category carries values for all three. Category names shorter than three characters and empty values are known to cause failures on this collection, so check the shortest names in your source data first. If the response body names a duplicate slug, change the source category's name or map the slug explicitly to a unique value. If all three fields are populated and the write still fails, contact iPaaS.com Support at support@ipaas.com with the full response body.

Description: An inventory record could not be created because the product it applies to was not identified. This applies to all four inventory collections — Product Inventory, Product Variant Inventory, and both standalone inventory update collections. The usual cause is that the product or variant has not yet been transferred to commercetools, so no link exists to attach the inventory record to. This error is documented in full under Product Variant FROM iPaaS.com, where the same message appears for the same reason.

Resolution: Transfer the product and its variants to commercetools before transferring inventory. Check the Error Logs for a product or variant failure earlier in the same run and resolve that first, then re-run the inventory transfer. Also confirm that a location is mapped on the inventory collection — an inventory record created in commercetools without a supply channel cannot be updated by this integration afterwards, so location should be treated as required rather than optional on all four inventory collections. See Known Limitations for the detail.

Description: commercetools rejected an inventory write. The cause is in the response body — most commonly a supply channel that does not exist in your project, or a quantity value that failed validation. The action name is spelled differently on the two paths, and Error Logs searches are case-sensitive. A failure creating an inventory record is logged as Inventory_POST (all capitals); a failure updating an existing one is logged as Inventory_Post (mixed case). Search for both spellings, or search for the shorter fragment Inventory_ so that either form matches. The difference is cosmetic and cannot be changed from the user interface. There is also a filing defect worth knowing about when you search: inventory update failures are recorded against the Product Category collection rather than Product Inventory in the Error Logs and Activity Tracker. If you are troubleshooting inventory and find nothing under the inventory collections, check the Product Category entries as well.

Resolution: Read the response body in the Error Logs entry. If it names the supply channel, confirm the corresponding location transferred to commercetools successfully and that the resulting channel exists in the Merchant Center. Confirm that MinQuantity is mapped — when it is left unmapped, newly created inventory records are written with an available quantity of zero, which reads as out of stock rather than as an error. Re-run the transfer once the source data is corrected. If the response body names no field, contact iPaaS.com Support at support@ipaas.com with the full entry, noting that the record may be filed under Product Category.