These are the known limitations of the Dotdigital integration on iPaaS.com. They are inherent to the current design of the integration and the capabilities of the Dotdigital API, and they apply to all subscribers at the time this documentation was written.

This integration was built for Dotdigital (the marketing platform formerly known as dotmailer). It calls the Dotdigital API at the regional host shown on your Dotdigital account's API users page (for example, r2-api.dotmailer.com), using the version 2 and version 3 endpoints for contacts, insight data, and triggered campaigns. It was last tested end-to-end against the Dotdigital production endpoints on 2026-06-30.

Not built for: Dotdigital is a single product, so there is no separate edition to point this integration at. If Dotdigital introduces a separate product line or a materially different API version in the future, this integration will not automatically support it.

The integration sends data from iPaaS.com to Dotdigital. It does not read records back from Dotdigital into iPaaS.com.

What this means for you: Dotdigital is the destination for contacts, orders, and loyalty certificates. Changes made directly in Dotdigital are not reflected back in iPaaS.com; the source system remains the source of truth for the data the integration sends.

The integration does not support an initialization (bulk first-load) mode. Records are sent as they are triggered or manually synced.

What this means for you: To load a large set of existing records into Dotdigital, subscribers or their MiSP can use the bulk sync using Postman approach rather than expecting a one-click historical import.

Dotdigital does not send change notifications back to iPaaS.com, so transfers run when an iPaaS.com outbound trigger fires or when a record is sent from the Manual Sync page.

What this means for you: Enable the relevant Customer, Transaction, and Gift Card outbound triggers under Outbound Data Flows so records sync automatically; until then, use Manual Sync. New activity in Dotdigital itself does not start a transfer.

Each contact transfer writes the full set of mapped contact fields (email, FIRSTNAME, LASTNAME, mobileNumber, emailType, optInType). Dotdigital data fields that are not part of the contact mappings are not maintained by the transfer.

What this means for you: If a Dotdigital data field should stay in sync with the source system, add a mapping for it on the contact collection. Data fields you manage only inside Dotdigital are left as they are, but any field the integration maps is overwritten on every transfer, so the source system is the source of truth for mapped fields.

The loyalty-certificate flow sends a certificate by triggering a Dotdigital campaign. A repeat transfer re-sends the campaign; there is no in-place update, and the integration does not provide a way to retrieve or remove a certificate already sent.

What this means for you: Treat each certificate transfer as a send. To correct a certificate, address the issue in the source data and in the Dotdigital campaign rather than expecting the integration to update a previously sent certificate.

The integration adds and updates records. Deleting a contact, order, certificate, product, product variant, or category in the source system does not remove the corresponding record from Dotdigital; the Dotdigital record remains in place.

What this means for you: Remove records in Dotdigital directly when they should no longer exist there. Because deletions are not propagated, any records left behind in Dotdigital after a source-side deletion should be cleaned up in Dotdigital as part of your housekeeping.

The integration matches contacts on email and mobile number, and the mobile number is read from a customer custom field. Dotdigital requires mobile numbers in E.164 international format, including the country code.

What this means for you: Populate the customer mobile custom field with E.164-formatted numbers (for example, +14155550123). Numbers in other formats may be rejected by Dotdigital or may not match the intended contact.

An order is stored against a Dotdigital contact identified by email, and the order's transactional email is sent through a Dotdigital campaign referenced by name.

What this means for you: Ensure the order's customer has a valid email address, and confirm the referenced order-confirmation campaign exists in Dotdigital, or the order will not link to a contact and its transactional email will not send.

When a product transfers, its category assignments are written onto the product's record in Dotdigital. Removing a category from the product in iPaaS.com and transferring again adds any new assignments but does not remove an earlier one from the Dotdigital record.

What this means for you: Treat category assignments as add-only. If a product should no longer belong to a category, remove that assignment from the product's record in Dotdigital directly; re-syncing from iPaaS.com will not clear it.

Each product, product variant, and category is stored in Dotdigital under an identifier derived from its iPaaS.com record id. A normal re-sync of the same record updates it in place. If a record is deleted and recreated in the source system, it receives a new iPaaS.com id and therefore transfers as a new Dotdigital record, leaving the original in place.

What this means for you: Update existing records rather than deleting and recreating them when you want the change to land on the same Dotdigital record. After a delete-and-recreate, expect a new Dotdigital record and remove the original in Dotdigital if it is no longer needed.

When the integration writes to a Dotdigital custom field, the field's key is taken from its name with spaces replaced by underscores and letters lower-cased. For example, a custom field named Product Category is written using the key product_category.

What this means for you: When you add a custom field mapping, name the Dotdigital custom field so that its derived key is what you expect. If a value does not appear where you anticipated, check that the field name produces the intended key under this rule.

Dotdigital caps each account at 1000 Insight Data collections. The integration creates only a small, fixed number of these collections per subscription — for order, product, and category data — so a single subscription does not approach the limit.

What this means for you: This ceiling becomes relevant only when many subscriptions or catalogs share one Dotdigital account. If you operate at that scale, account for the shared 1000-collection limit when planning how many subscriptions point at the same Dotdigital account.

The Dotdigital order (transaction) collection is created by the integration as an order-type Insight Data collection, and its field structure is established from the records written to it. Dotdigital does not provide a way to change a collection's type or reshape its established fields afterward.

What this means for you: Let the integration create and manage the order collection, and point the order collection-name setting at a dedicated collection for this integration. Avoid reusing a pre-existing Dotdigital collection that was created for another purpose or with a different structure — a mismatch in structure can cause order transfers to be rejected. If the order structure ever needs to change, use a new collection name rather than expecting an existing collection to be reshaped.

Dotdigital's order (transaction) schema defines a standard set of order fields — such as order total, subtotal, currency, status, purchase date, billing and delivery address, line items, discount amount, and coupon code. Additional order details can be stored on the order record and used for segmentation, but only the standard order fields drive Dotdigital's built-in order features, such as purchase-history segmentation and product recommendations.

What this means for you: Map the standard order fields to get the most from Dotdigital's order features. Any extra order data beyond the standard fields is retained and available for segmentation, but should not be relied on to feed Dotdigital's built-in order features.

An order is stored against the contact under a key derived from its transaction number, so re-transferring the same transaction updates the existing order record rather than creating a duplicate.

What this means for you: You can safely re-sync an order to apply changes — it updates the same Dotdigital order record. To have a change land on the same record, re-sync the same transaction rather than creating a new one with a different transaction number.

Version 1.0.5 renamed the setting that names the Dotdigital collection for order data from Collection Name to Order Collection Name, so that it reads clearly alongside the product and product-category collection settings introduced in the same release. The new setting starts out empty, and a value entered against the old setting is not carried across to it automatically. When Order Collection Name is empty, orders are written to a collection named Purchases.

What this means for you: If you left the setting blank, nothing changes — blank meant Purchases before the rename and still does. If your subscription was configured before version 1.0.5 and you had entered your own collection name for orders, confirm that Order Collection Name holds that same name before any further orders are sent. Until it does, new orders are written to Purchases rather than to your collection, and no error is recorded — so the change is easy to miss, and your order history ends up split across two collections. In most cases iPaaS.com or your MiSP applies this change for you as part of the upgrade; the steps, and how to recover orders that were already written to the wrong collection, are in the Dotdigital Background article.

The integration sends an order's totals, line items, addresses, taxes, notes and discounts. It does not send the order's payment details — the payment method, amount, status or description. Orders that carry payment information in the source system still transfer normally; the payment simply is not part of what is written to Dotdigital.

What this means for you: Do not plan segments or automations around how an order was paid for. If payment method matters to your Dotdigital campaigns, raise it during implementation so it can be considered as a change of scope rather than assumed to be available.

Product data is written to a Dotdigital Insight Data collection, and the Product Collection Type setting decides how Dotdigital treats it. The catalog type takes part in Dotdigital's native product features — product catalogs, recommendations, and category filtering. The custom type does not; it exists to support custom fields on products.

The choice applies to the whole collection rather than to individual products, so it is not possible to have some products take part in native product features and others not. Dotdigital fixes a collection's type when the collection is created and provides no way to change it afterwards. The two types also use different collection names — the catalog type writes to a collection prefixed catalog_ — so changing the setting later starts writing to a different collection and leaves every product already transferred behind in the original, with no migration.

What this means for you: decide the collection type before the first product transfers, and treat it as permanent. If products have already synced under the wrong type, they must be re-transferred into the new collection and the old collection removed in Dotdigital. This reflects the integration's behavior at the time this documentation was written.

Product Collection Name and Product Category Collection Name must be given the same base name. The integration adds the prefix each collection needs, and Dotdigital pairs a product collection with its categories by that shared base name.

What this means for you: if the two settings are given different base names, products and their categories both transfer successfully and no error is recorded, but the categories do not resolve against the products. Confirm both settings match before assigning categories. This reflects the integration's behavior at the time this documentation was written.

An order's line items are written as the products on the Dotdigital order record. If a line is missing values, or if an order has no lines at all, the order still transfers successfully and nothing is recorded as an error — the missing detail is simply absent from the Dotdigital record.

Three cases behave this way. A line with no description lands with no product name against it. A line with no unit price, or no quantity, lands with that value recorded as zero, so the line also contributes nothing to the order's product value. An order with no lines at all transfers with no products recorded against it, which leaves it out of product recommendations and out of any segment built on what was purchased.

What this means for you: Treat line completeness as something to confirm in your source data rather than something the transfer will flag for you. Check that every order line carries a description, a unit price and a quantity before it syncs, and that orders reaching the integration have lines at all. If an order looks right in Dotdigital at the header but shows unnamed products, zero prices or quantities, or no products at all, the cause is almost always missing values on the source order rather than a failed transfer. Correct the source and re-sync the same transaction — it updates the existing order record in place, as described in section 15.

Category names do not have to be unique. The same name can appear in more than one place in a catalogue — a Clothing category under Adults and another under Kids, for example. Each transfers to Dotdigital as its own record, with its own id and its own parent, so the two are stored as genuinely separate categories.

A Dotdigital category record holds its id, its name and its parent. Where a name repeats, the records are correct but they read alike wherever categories are listed by name, including the segment builder, so the name alone does not always make clear which one is which.

What this means for you: Product assignments are unaffected — they resolve by id, so a product is only ever assigned to the specific category it belongs to, and a repeated name cannot cause a product to land in the wrong one. When you build a segment on a category whose name appears more than once, confirm you have the intended one by its parent rather than choosing on the name. If your catalogue reuses names heavily and you would rather tell them apart at a glance, give those categories distinct names in iPaaS.com; a renamed category updates its existing Dotdigital record in place, so this can be done after they have synced.

Several mappings ship with example values that each subscriber must replace before enabling the affected collection. Review and replace each of the following:

This document describes twenty-one known limitations of the Dotdigital integration, plus the placeholder values to replace before go-live. For the detailed behavior of each mapping collection, see the Dotdigital mapping documentation.