Poll — the integration periodically checks commercetools for customers whose last-modified time is later than the previous check, and captures those customers. No automatic transfers occur until polling is enabled for the subscription.

Manual Sync — available from the iPaaS.com Manual Sync page at any time, independent of the polling schedule, on the parent collection only.

Add/Update commercetools Customer FROM iPaaS.com — writes customers from iPaaS.com into commercetools.

Add/Update commercetools Customer Address FROM iPaaS.com — writes addresses from iPaaS.com into commercetools, as a child of that collection.

The child has no independent trigger and no Manual Sync entry point of its own. It cannot be dispatched, filtered or manually synced on its own.

No mapping in the child carries a customer identifier, and none needs to be added — the parent supplies the linkage.

To transfer an address, transfer its customer: run Manual Sync on the parent with the commercetools customer identifier.

Enabling or disabling the child controls whether addresses accompany the customer; it does not create a separate address sync.

Intake is polling-based. A change made in commercetools becomes visible in iPaaS.com on the next poll cycle, not at the moment it is saved.

A poll cycle can permanently skip changed customers. Each 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. This is data loss, not a delay. Manual Sync is the only recovery. See Known Limitations.

The commercetools Customer Number field is not read. It is optional and merchant-assigned. The CustomerNumber mapping captures the commercetools customer identifier instead. Subscribers who maintain human-readable customer numbers in commercetools and need them in iPaaS.com must repoint that mapping — before the first transfer, not after customers have already been created.

commercetools holds both a region and a state value on an address, and this integration reads the state value. Subscribers who record their province, state or county in the commercetools region field will see the iPaaS.com Region arrive empty. Confirm which of the two fields the storefront populates and repoint the mapping if it is the region value, before the first transfer.

The street number is a separate value from the street name, and only the street name is captured. In markets where shoppers enter the house or building number in its own field, iPaaS.com addresses arrive without it.

The country is a two-letter code. Addresses arrive in iPaaS.com carrying the code rather than a country name; downstream systems expecting a full country name need a translation applied.

Email uniqueness is not guaranteed by commercetools when a customer belongs to a store, while iPaaS.com does require it on create.

commercetools requires a country on every address. The remaining address values are optional in commercetools and may legitimately be empty.

Request limits and per-project quotas apply. commercetools publishes them at https://docs.commercetools.com/api/limits (retrieved 2026-07-20); most are configurable per project, a few are hard limits. commercetools also bounds the shape of an individual query — the limit parameter accepts a value between 0 and 500 and defaults to 20 on most query endpoints (https://docs.commercetools.com/api/general-concepts, retrieved 2026-07-20). This documentation makes no claim that a request declined for a limit is retried or resumed on the subscriber's behalf. Treat a declined request as a failed transfer: monitor Dashboard / Integration Monitoring / Error Logs, re-run affected records with Manual Sync, and validate expected throughput in a staging environment before relying on it in production.

A customer number and an email address are required on every iPaaS.com customer. Both are mapped by default and both are always present on a commercetools customer.

At least one of First Name, Last Name or Company must be supplied on an iPaaS.com customer. All three are mapped by default, so the condition is satisfied.

The email address must be unique across customers when a customer is created.

No field is required on a customer address beyond its link to a customer, which the parent supplies. An incomplete commercetools address transfers successfully and arrives incomplete — the integration will not reject it. Subscribers should confirm that the detail their downstream systems depend on, commonly Address 1, City, Postal Code and Country, is actually populated in commercetools.

Addresses arrive without a primary shipping or primary billing designation, because neither value is mapped. Set it in iPaaS.com, or add the mapping.

Delete is not supported for any entity in either direction.

Initialization is not supported. There is no bulk first-load step; use Manual Sync to bring historical customers across.

Only the values listed in the mapping tables below are captured. Any other commercetools customer or address detail a subscriber needs in iPaaS.com must be added as an additional mapping.

The integration does not transfer any dependent record automatically ahead of a customer. Nothing else needs to exist in iPaaS.com before a customer transfers.

The address-level company is distinct from the company name on the parent customer record; both are captured, into different iPaaS.com fields.

A commercetools project with customers to transfer, reachable through the credentials configured for the subscription.

No webhook or subscription needs to be created in commercetools for this family. There is no inbound webhook event to subscribe to — customer intake is polling-based only.

A decision on which commercetools field holds the subscriber's state or province value, and which field holds their customer number, before the first transfer.

A configured and authorized commercetools connection for the subscription. The credential set and the region constraint are covered in commercetools Connections and Settings; the full setup walkthrough is in commercetools Installation Instructions.

Polling enabled for the integration, if customers are to transfer without manual intervention.

Both collections enabled, if addresses are to accompany the customer.

A decision on the system of record for customer data, if the opposite-direction customer collection is also enabled.

"Error calling CommerceTool CallWrapper.{action}: {response body} (Http Code: {status})" — commercetools returned a non-success HTTP status while the customer was being read. The useful detail is the response body, which carries the text commercetools itself reported. A 429 means the project's request rate was exceeded. Resolution: read the response body in the Error Logs entry and correct the source record or the mapping it names. Transfers are not automatically rescheduled or resumed by this integration — stagger large jobs, avoid running several intensive transfers at once, and re-run the affected records with Manual Sync.

Email address already in use — reported by iPaaS.com when a create carries an email address that already belongs to another iPaaS.com customer. This is the expected outcome when two commercetools customers share an email address. Resolution: correct the duplicate in commercetools, or decide which of the two customers should exist in iPaaS.com, then re-run the transfer for that customer.

"Call to PollRequest with unhandled parameters: System=CommerceTool {collection}, sourceObject could not be created" — the poll ran but the customer record it was to work on could not be constructed. Resolution: confirm the collection is configured for the customer record type and that the commercetools connection is authorized, then re-run. If the configuration is correct, contact iPaaS.com Support at support@ipaas.com with the Error Logs entry.

"The method or operation is not implemented." — a delete was requested for a commercetools customer or address. Delete is not supported. Resolution: remove any configuration that asks the integration to delete a commercetools record.

No message at all — a customer skipped by a poll cycle produces no error and no entry in the Error Logs. Nothing in the logs will indicate that a record was missed. Resolution: reconcile expected customers after each cycle and re-sync any that are absent by their commercetools customer identifier.

The iPaaS.com customer number must be present. It is supplied from the commercetools customer identifier, which always exists.

The iPaaS.com email address must be present and must be unique across customers when a customer is created.

At least one of the iPaaS.com First Name, Last Name or Company must be supplied. All three are mapped, so the rule is satisfied by default and only fails if all three are unmapped or all three are empty in commercetools.

No validation rule is enforced on a customer address beyond its link to a customer, which the parent transfer supplies. Address completeness is not validated by either system.

Neither collection applies a mapping filter, so no record is rejected on filter grounds.

Create and capture a new customer. Register a new customer in commercetools with a first name, last name and email address, wait for the next poll cycle, and confirm an iPaaS.com Customer is created with the matching Customer Number, Email Address, First Name, Last Name and Company. Expected outcome: one new iPaaS.com customer, no duplicate.

Update an existing customer. Change the last name on a customer already captured in iPaaS.com and confirm the change propagates on the next poll. Expected outcome: the existing iPaaS.com customer is updated, not duplicated, because the external-ID record matched.

Verify the Manual Sync ID format. Run a Manual Sync on Add/Update commercetools Customer TO iPaaS.com using a 36-character commercetools customer identifier such as fbd9c195-5028-46b3-b85d-016dc6e2f9b9 and confirm the transfer succeeds. Repeat with a value that is not a commercetools customer identifier — for example the merchant-assigned customer number — and confirm the transfer fails rather than matching the wrong record.

Verify parent-child transfer. Add two addresses to a commercetools customer's address book, re-sync the customer, and confirm both arrive as separate iPaaS.com customer addresses attached to that customer. Confirm there is no way to sync an address without its customer.

Verify the email uniqueness failure. Create a second commercetools customer with an email address already used by a captured iPaaS.com customer and confirm the transfer fails with a message in the Error Logs rather than silently overwriting the first customer.

Verify the region field. Populate the commercetools address state value on one test address and the commercetools region value on another. Confirm the first arrives with an iPaaS.com Region and the second arrives with Region empty. This confirms which commercetools field the storefront should be using before go-live.

Verify the street address. Enter a house or building number in the commercetools street-number field and confirm it does not arrive in Address 1. Decide before go-live whether the mapping needs extending.

Verify poll capacity. Change more customers in commercetools between two poll cycles than a single page can carry, then reconcile the arrivals against the changes made. Any customer missing from iPaaS.com with no Error Logs entry demonstrates the skip behavior described in Known Limitations and should be recovered with Manual Sync.

The commercetools connection is configured and authorized for the subscription.

Polling is enabled, if customers are to transfer without manual intervention.

Both Add/Update commercetools Customer TO iPaaS.com and Add/Update commercetools Customer Address TO iPaaS.com are enabled.

The system of record for customer data has been decided, if the opposite-direction collections are also enabled.

It has been confirmed whether the CustomerNumber mapping should stay on the commercetools customer identifier or be repointed at the merchant-assigned customer number — and the decision was made before the first transfer.

It has been confirmed which commercetools field the storefront uses for state or province, and the Region mapping matches it.

A decision has been recorded on whether the commercetools street number needs to be added to the Address 1 mapping.

A sample customer has transferred end to end with its addresses, and the values in iPaaS.com match commercetools field for field.

A repeat transfer of the same customer updates rather than duplicates.

Dashboard / Integration Monitoring / Error Logs has been checked after the first cycles, and a reconciliation of expected against arrived customers has been performed at least once.

Deleting customers or addresses in either system.

Customer groups, stores, authentication mode, password and password-reset state, date of birth, VAT identifier, middle name, title and salutation.

The commercetools street number, additional street info, building, apartment, PO box, department, address key and address external identifier, and the address-level email, phone, mobile and fax values.

Address type, and the primary billing and primary shipping designations.

Custom fields on either the commercetools customer or the commercetools address.

Writing anything back to commercetools. Subscribers who need iPaaS.com customers published into the storefront should review Add/Update commercetools Customer FROM iPaaS.com, which runs in the opposite direction and carries its own separate behaviors.