Introduction
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.
Platform Scope and Tested Versions
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.
1. Synchronization is one-way to Dotdigital
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.
2. Initialization and bulk historical import are not supported
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.
3. Transfers are driven by iPaaS.com triggers and Manual Sync
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.
4. Contact updates replace the mapped fields
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.
5. Loyalty certificates are send-only
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.
6. Deletions are not transferred
The integration adds and updates records. Deleting a contact, order, or certificate in the source system does not remove the corresponding record from Dotdigital.
What this means for you: Remove records in Dotdigital directly when they should no longer exist there.
7. Mobile-based contact matching requires E.164 numbers
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.
8. Orders require a contact email and an order-confirmation campaign
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.
Placeholder Values to Replace Before Go-Live
Several mappings ship with example values that each subscriber must replace before enabling the affected collection. Review and replace each of the following:
Where | Placeholder value | Replace with |
Loyalty Certificate — recipient email | A fixed test email address | The recipient's email drawn from the source record, so each certificate reaches the correct contact |
Loyalty Certificate — triggered campaign id | An example campaign id | The id of your own active loyalty-certificate triggered campaign in Dotdigital |
Loyalty Certificate — certificate link | An unrelated sample image link | A valid HTTPS link to your certificate or gift-card page |
Transaction — currency | USD | The currency your orders are placed in (ISO 4217), or an order currency field |
Transaction — order-confirmation campaign | A campaign named OrderConfirmation | A campaign of that name created in Dotdigital, or the name of your existing order-confirmation campaign |
Summary
This document describes eight 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.