Summary

This integration sends an iPaaS.com Transaction to Dotdigital as order insight data. Each order is written as a record in Dotdigital's contact insight data and stored against the contact it belongs to, so that order history, transactional campaigns, and reporting in Dotdigital reflect the iPaaS.com order. The order's line items, taxes, notes, and discounts transfer with it through four child collections, so a single transfer carries the order and everything recorded against it.

This is an Add/Update flow. An order carrying a transaction key that does not yet exist in Dotdigital is created, and a repeat transfer of the same key updates the existing order record in place rather than creating a duplicate. The update replaces the values held against that key - changed order values, line values, taxes, notes, and discounts all overwrite what was sent before - rather than adding a second order or accumulating duplicates alongside the originals. The flow is one-way, from iPaaS.com to Dotdigital.

The order's payment details are not sent. Orders carrying payment information in the source system transfer normally; the payment method, amount, status, and description are simply not part of what is written.

ID Format

Manual Sync ID — the transaction key and the contact email joined by a vertical bar, in the form transaction key, a vertical bar, then the contact email (for example, 13|john.doe@example.com). Both parts are entered on the iPaaS.com Manual Sync page when an order is transferred on demand.

External ID Format

After a successful transfer, iPaaS.com records the order's stored key so that later transfers of the same order upsert the same insight-data record rather than creating a duplicate.

Each child record - line, tax, note, and discount - is linked separately, under its own iPaaS.com id combined with its parent order's id, joined by a vertical bar (for example, 57768|163168). A child is only linked when its collection maps an Id destination field; without that mapping the child still appears inside the order in Dotdigital, but no link is recorded against the iPaaS.com record.

Deleted Record Support

Deleted records are not supported. This is an Add-only flow: it creates and updates order insight data in Dotdigital, and deletions do not propagate. Removing an order in iPaaS.com does not remove the corresponding order from Dotdigital.

Custom Field Support

Dotdigital order insight data can carry additional fields beyond the shipped mappings. Subscribers or their MiSP can extend any of these collections to map additional iPaaS.com values into the order's insight data as needed.

One worked example ships, on the parent order collection: DD_OrderSubtotal, which sends the order subtotal a second time as a custom field alongside the standard OrderSubtotal field. It exists so the behavior below is visible on a real mapping, and it can be removed if it is not wanted. The child collections ship without any custom field, so subscribers start from a clean set and add only what they need.

Two things are worth knowing before adding your own:

The Dotdigital key is derived from the field name. Spaces become underscores and every letter is lower-cased, so a field named DD_OrderSubtotal arrives in the order record as dd_ordersubtotal. Name a custom field so that the key this produces is the one you expect to find when building a segment. Because the key comes from the name, renaming a field starts a new key - values written before the change stay under the old key and are not moved, so settle on a name before go-live rather than renaming afterwards.
A mapping on its own is not enough. The source custom field must also be registered in iPaaS.com against the specific record type it belongs to - Transaction, Transaction Line, Transaction Tax, Transaction Note, or Transaction Discount. If it is mapped but not registered, the order is rejected when the record is created rather than at transfer time.

Mapping Collection Status

Status — Enabled.

Trigger Events — Transaction Create, enabled under Outbound Data Flows. No automatic transfers occur until the Transaction created event is subscribed to.

Duplicate or Conflicting Mappings

There is no collision handling, because no other collection writes Dotdigital order insight data. Create-versus-update routing is handled within this single collection by the order's transaction key: a repeat transfer carrying an existing transaction key updates the existing order in place instead of duplicating it, and a new key creates a new order.

No duplicate checking is required for the order or for any of its child collections. Dotdigital matches on the transaction key and upserts - if the key exists the record is updated, and if it does not a new one is created. The lines, taxes, notes, and discounts are written inside the same order payload rather than as separate calls, so they are covered by that same upsert and need no independent duplicate or existence check of their own.

Supported Child Collections

Add/Update Dotdigital Transaction Line FROM iPaaS.com — the order's line items.

Add/Update Dotdigital Transaction Tax FROM iPaaS.com — the order's tax lines.

Add/Update Dotdigital Transaction Note FROM iPaaS.com — the order's notes and comments.

Add/Update Dotdigital Transaction Discount FROM iPaaS.com — the order's discounts.

All four are read from the Transaction and written together with the parent order in the same transfer. There is no independent transfer path for a single child record, and because the order is written as a whole, a repeat transfer replaces the child values held against it rather than appending to them.

System Caveats

Dotdigital Caveats

CollectionScope and CollectionType are mandatory. Dotdigital rejects the record if either is missing; they are set to contact and orders respectively.
The currency must be a valid ISO 4217 code (for example, USD, GBP, EUR).
The referenced transactional-email campaign must already exist in the connected Dotdigital account. If it does not, the lookup returns nothing and no transactional email is sent for the order.

iPaaS.com Caveats

The order is stored against a contact resolved by email, so a Transaction whose customer has no email on record cannot be linked to a contact.
The insight-data collection the order is written to is named by the Order Collection Name subscription setting, which defaults to Purchases when left blank. This setting was named Collection Name before version 1.0.5.

Setup Requirements

In Dotdigital, create an API user with permission to access the insight-data and campaign APIs.
In Dotdigital, create the order-confirmation triggered campaign the order's transactional email should use, and update the campaign reference on this collection to match it.
In iPaaS.com, enter the Dotdigital API User and API Password, and set the Order Collection Name if a value other than Purchases is required.

Integration Flow

An iPaaS.com Transaction is transferred, either automatically when the Transaction created outbound trigger fires or on demand from the Manual Sync page.
The integration resolves the Dotdigital contact the order belongs to from the order's customer email address.
The integration ensures the insight-data collection named by the Order Collection Name setting (default Purchases) exists, creating it if necessary.
The integration writes the order — including its line items, taxes, notes, and discounts — to that insight-data collection against the contact, keyed on the order's transaction key. A key that already exists updates the existing order; a new key creates a new one.

Mappings

Add/Update Dotdigital Transaction FROM iPaaS.com

This parent collection writes the order record. There is no mapping filter applied: every iPaaS.com Transaction reached through an enabled outbound trigger or Manual Sync is processed.

Mapping Type	Source Field (iPaaS.com)	Destination Field (Dotdigital)	Description
Field	EmailAddress	ContactIdentifier	Required. The email address of the contact the order belongs to. Dotdigital attaches the order's insight data to this contact, so the transfer cannot complete without it.
Dynamic Formula	`var CustomerEmail =await ContactEmailUsingId(CustomerId);` `return CustomerEmail;`	Identifiervalue	Required. Resolves the contact's email address from the order's customer. If the customer has no email on record, the order cannot be linked to a contact.
Static	`"email"`	IdentifierType	Required. Tells Dotdigital the contact is identified by email. Leave it set to email.
Field	TransactionNumber	Id	Required. The order's unique identifier in Dotdigital, taken from the iPaaS.com transaction number. Must be unique for each order.
Field	TransactionNumber	TransactionKey	Required. The key Dotdigital uses to match an order on repeat transfers. A transfer carrying a key that already exists updates the existing order, so the value must be unique per order.
Static	`"orders"`	CollectionType	Required. Identifies the insight-data collection type as orders. Leave it set to orders.
Static	`"contact"`	CollectionScope	Required. Identifies the collection scope as contact, so the order data is stored against individual contacts. Leave it set to contact.
Field	Status	OrderStatus	Recommended. The status of the order, taken from the iPaaS.com transaction status. Supports order-status reporting and triggered programs.
Dynamic Formula	`ToDotDigitalDateFormat(TransactionCreatedDateTime)`	PurchaseDate	Recommended. The date and time the order was placed, taken from the transaction's created date and converted into the format Dotdigital expects. Used for order-date reporting and time-based automations.
Field	Subtotal	OrderSubtotal	Recommended. The order subtotal before tax, shipping, and discounts, taken from the iPaaS.com transaction subtotal. Used for revenue reporting.
Field	Total	OrderTotal	Recommended. The final order total, taken from the iPaaS.com transaction total. Used for revenue reporting.
Field	Total	BaseSubtotalInclTax	Recommended. The order subtotal including tax, taken from the iPaaS.com transaction total. Supports tax-inclusive revenue reporting.
Field	EmailAddress	Email	Recommended. The contact's email address recorded on the order, taken from the iPaaS.com customer email. Carries the order's contact email alongside the identifier used to attach the order.
Static	`"iPaaS.com"`	SalesChannel	Recommended. Labels the channel the order came through. Subscribers or their MiSP may change it to the name of the sales channel or store the orders originate from for channel-level reporting.
Static	`"USD"`	Currency	Recommended. The currency the order is recorded in, as an ISO 4217 code. Placeholder value — replace during implementation: set it to the currency your orders are actually placed in, or map it from an order currency field.
Dynamic Formula	`await CampaignIdFromNameAsync("OrderConfirmation");`	TransactionalEmailCampaignId	Recommended. Resolves the Dotdigital campaign used to send the order's transactional email by looking it up by name. Placeholder value — replace during implementation: a campaign named OrderConfirmation must already exist in Dotdigital, or change the name to match your existing order-confirmation campaign.
Field	DiscountAmount	DiscountAmount	Optional. The total discount applied to the order, taken from the iPaaS.com transaction discount amount. Supports promotion and discount reporting.
Field	ShippingAmount	DeliveryTotal	Optional. The shipping (delivery) charge on the order, taken from the iPaaS.com transaction shipping amount. Supports shipping-cost reporting.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Address1");`	DeliveryAddress1	Optional. The first line of the delivery address, taken from the first address on the order marked as the primary shipping address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Address2");`	DeliveryAddress2	Optional. The second line of the delivery address, taken from the first address marked as the primary shipping address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "City");`	DeliveryCity	Optional. The delivery city, taken from the first address marked as the primary shipping address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "PostalCode");`	DeliveryPostcode	Optional. The delivery postal code, taken from the first address marked as the primary shipping address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Country");`	DeliveryCountry	Optional. The delivery country, taken from the first address marked as the primary shipping address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Address1");`	BillingAddress1	Optional. The first line of the billing address, taken from the first address on the order marked as the primary billing address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Address2");`	BillingAddress2	Optional. The second line of the billing address, taken from the first address marked as the primary billing address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "City");`	BillingCity	Optional. The billing city, taken from the first address marked as the primary billing address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "PostalCode");`	BillingPostcode	Optional. The billing postal code, taken from the first address marked as the primary billing address.
Dynamic Formula	`FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Country");`	BillingCountry	Optional. The billing country, taken from the first address marked as the primary billing address.
Field	Subtotal	DD_OrderSubtotal (custom field)	Optional. The order subtotal sent a second time as a custom field, alongside the standard OrderSubtotal. This is the integration's worked example of a custom field and carries no data the standard fields do not already carry; remove it if it is not wanted. It lands in the order record as dd_ordersubtotal — see Custom Field Support above for how the key is derived.