See what the commercetools integration can do →

This article lists every commercetools API endpoint the iPaaS.com integration calls. Use it to whitelist hosts on a firewall, to confirm the API client scope covers the operations the integration performs, and to determine quickly whether a commercetools deprecation notice affects your subscription.

Areas covered: Customer · Product · Product Variant · Product Attribute Definition · Inventory · Category · Location · Order · Payment · Tax Category · Authorization

The Merchant Center is the web-based portal where business and developer teams log in to manage projects, products, customers, orders, and settings. The URL depends on the cloud region that hosts your project. Choose the Merchant Center URL that matches your project's region.

The hosts below follow the same regional naming pattern commercetools publishes for its API and authorization hosts, but commercetools does not publish them as a single list. Treat the table as a guide and confirm your own Merchant Center address from the browser once you have signed in — that address is authoritative for your project.

If your project is hosted in North America (Google Cloud, Iowa), your Merchant Center URL is https://mc.us-central1.gcp.commercetools.com.

commercetools provides a REST API. Every endpoint in this article is a REST call.

The API host depends on the cloud region that hosts your project. Region names and host URLs below are taken from the commercetools API documentation (https://docs.commercetools.com/api/general-concepts, retrieved 2026-07-20).

Throughout this article, [Base URL] stands for the API host for your region followed by your commercetools project key:

This is exactly the value you enter in the API URL subscription setting described in Connections and Settings. The integration appends each endpoint path in this article to that value, so the setting must include the project key — a host on its own will not work.

Example. A project keyed mystorename hosted in North America (Google Cloud, Iowa) gives:

That value is the API URL setting, and it is what [Base URL] resolves to in every endpoint below.

Read this before selecting a region. 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). The five published authorization hosts are listed under Authorization Endpoint below.

This integration as currently released obtains its access token from the North America (Google Cloud, Iowa) authorization host only, regardless of which region you enter in the API URL setting. It therefore does not meet the region-matching requirement commercetools documents. A project hosted in any of the other four regions cannot complete authentication, and every transfer will fail at the authorization step rather than at the endpoint being called.

Until this is addressed, subscribers should treat the integration as supported for North America (Google Cloud, Iowa) projects only. If your project is hosted elsewhere, contact iPaaS.com Support before beginning implementation. This constraint is also recorded in the Known Limitations article for this integration.

Non-production testing is isolated with a separate project rather than with a separate host: create a second commercetools project in the same region and point a separate iPaaS.com subscription at that project's key. The host is identical for both; only the project key portion of the API URL changes.

The integration uses three commercetools query parameters. The semantics, defaults, and maximums below are taken from the commercetools API documentation (https://docs.commercetools.com/api/general-concepts, retrieved 2026-07-20).

Both limit and offset are optional, and commercetools applies its default of 20 when they are omitted.

This matters for the two polling flows. The scheduled customer and order polls query commercetools for records changed since the last check without supplying limit or offset, so each poll run returns at most the default page of changed records. Any records beyond that page are not carried into iPaaS.com on that run, and because the integration advances its last-checked marker afterwards, they are not picked up on a later run either. No error is raised. If your storefront can produce more changed customers or orders between two poll cycles than a single default page holds, shorten the polling interval so fewer records change within one window, confirm after each cycle that every expected record arrived, and use Manual Sync to bring across anything missing. This behavior is described in full in commercetools Known Limitations.

Two consequences follow from the maximums above. No single request can return more than 500 records, so any result set larger than that is retrieved over several requests. And because offset cannot exceed 10,000, paging alone cannot walk past the ten-thousandth record of a result set — larger sets have to be narrowed by a where predicate rather than paged through in full.

commercetools publishes resource count limits — caps on how many objects a project may hold — on its limits page (https://docs.commercetools.com/api/limits, retrieved 2026-07-20). The figures most likely to affect a transfer are:

As of the retrieval date above, commercetools does not publish a request rate limit, a requests-per-second figure, or a documented throttling response on that page. Because no published rate figure exists, subscribers should not assume a safe request volume. Two practical consequences:

Errors returned by commercetools are surfaced in iPaaS.com under Integration Monitoring and Error Logs on the Dashboard. See the Error Messages article for this integration for the specific messages you may encounter.

Used during transfers to iPaaS.com to find every customer changed since the last successful poll.

Used to retrieve the full customer record after polling has identified it, and to read the current record before an update is applied.

Used during transfers from iPaaS.com to create a customer that does not yet exist in commercetools.

Used during transfers from iPaaS.com to apply changes to an existing customer. commercetools applies updates as a list of actions against the record's current version, so this is a POST rather than a PUT or PATCH.

Used to retrieve the full product record, and to read the current version before an update is applied.

Used during transfers from iPaaS.com to create a product that does not yet exist in commercetools.

Used during transfers from iPaaS.com to apply product changes to an existing record.

commercetools does not expose variants as a separately addressable resource. Variants are created, changed, and removed through update actions on their parent product, so all variant work is performed against the product endpoint.

Attribute definitions in commercetools belong to a product type, so all attribute work is performed against the product type resource.

Used to locate the product type that owns an attribute definition, addressed by its key.

A second product-type lookup path. Subscribers should validate product-type resolution in a staging project before relying on it, and watch Dashboard / Integration Monitoring / Error Logs for not-found responses on product-type lookups.

Used during transfers from iPaaS.com both to add or change an attribute definition on a product type, and to add enumeration values to an existing attribute definition. Both operations are update actions against the same endpoint.

These endpoints serve both product-level and variant-level inventory. commercetools stores both as inventory entries on the same resource.

Used to read the current inventory entry, including its version, before an update is applied.

Used during transfers from iPaaS.com to create an inventory entry that does not yet exist.

Used during transfers from iPaaS.com to apply quantity and supply channel changes to an existing inventory entry.

Used to retrieve the category tree a page at a time. See Query Parameters above for how offset and limit page through the full set.

Used to retrieve a single category, and to read its current version before an update is applied.

Used to resolve a category by its key — for example, when locating the parent category a new category must be filed under.

Used during transfers from iPaaS.com to create a category that does not yet exist.

Used during transfers from iPaaS.com to apply changes to an existing category.

Locations map to commercetools channels. A channel used for inventory is what commercetools calls a supply channel.

Used to retrieve existing channels a page at a time so an incoming location can be matched to one. See Query Parameters above for how offset and limit page through the full set.

Used to retrieve a single channel, and to read its current version before an update is applied.

Used during transfers from iPaaS.com to create a channel for a location that does not yet exist in commercetools.

Used during transfers from iPaaS.com to apply changes to an existing channel.

Used during transfers to iPaaS.com to find every order changed since the last successful poll.

Used to retrieve the full order record, including its line items, addresses, taxes, and payment references, after polling has identified it.

Used during order transfers to iPaaS.com to resolve each payment referenced by an order into its full payment record.

Used to retrieve the project's tax categories a page at a time so an order's tax lines can be resolved. See Query Parameters above for how offset and limit page through the full set.

Used to resolve a single tax category referenced by an order or a product.

commercetools uses OAuth 2.0 with the client credentials grant. The integration requests an access token before making API calls and sends that token on every subsequent request.

The Client ID, Client Secret, and Scope values used here are the ones you enter in the subscription settings described in Connections and Settings. The Client ID and Client Secret are sent as HTTP Basic authentication credentials; the grant type and scope are sent in the request body.

The authorization host does not follow your API URL region. commercetools publishes a separate authorization host per region and requires 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). The published hosts are:

The token endpoint is POST /oauth/token with the client_credentials grant on every host. This integration always requests its token from the North America (Google Cloud, Iowa) host shown above and never derives the host from your API URL, so it does not satisfy the region-matching requirement for the other four regions. This is the mechanism behind the constraint described under Region Availability Constraint earlier in this article.

If your access scope does not cover an operation listed in this article, the call fails at commercetools rather than at iPaaS.com. Granting the Manage Project permission when creating the API client covers every endpoint in this article; see Connections and Settings for the scope format.