Summary

This integration sends an iPaaS.com Product to Dotdigital as a product record in an account-level Insight Data collection, so that product data is available to Dotdigital's product features and to campaign content. Products sold in variations also transfer their variants, through the child collection Add/Update Dotdigital Variant FROM iPaaS.com.

This is an Add/Update flow. A product whose id does not yet exist in the Dotdigital collection is created, and a repeat transfer of the same id updates the existing record in place rather than creating a duplicate. The flow is one-way, from iPaaS.com to Dotdigital.

Assigning categories to products is optional. Products transfer with or without them, and the category flow is documented separately in Dotdigital Product Category From iPaaS.com Mapping Documentation.

Choosing the Collection Type

This is the decision to get right before the first product transfers. The Product Collection Type setting decides how Dotdigital treats the collection this integration writes to.

Type	What it gives you	When to choose it
catalog	The collection takes part in Dotdigital's native product features — product catalogs, product recommendations, and category filtering.	The default choice for product data.
custom	A plain Insight Data collection. Product data transfers and is available for segmentation, but the collection does not take part in Dotdigital's native product features.	Only when custom fields on products are required, which is the trade-off this type exists for.

Three properties of this setting make it a go-live decision rather than something to revisit:

It applies to the whole collection, not to individual products. Every product written to a collection is treated the same way, so it is not possible to have some products take part in native product features while others do not.
It cannot be changed after the collection is created. Dotdigital fixes a collection's type at creation and provides no way to convert it.
Changing the setting later does not move anything. The two types use different collection names — the catalog type writes to a collection prefixed catalog_, the custom type to a collection named exactly as the setting says. Changing the setting starts writing to a different collection and leaves every product already transferred behind in the original.

If products have already synced under the wrong type, the correction is to set the intended type, re-transfer the products so they land in the new collection, and remove the old collection in Dotdigital.

Naming the Collections

Product Collection Name and Product Category Collection Name must be given the same base name. The integration adds the prefix each collection needs.

Setting	Value entered	Collection created
Product Collection Name (catalog type)	`springline`	`catalog_springline`
Product Collection Name (custom type)	`springline`	`springline`
Product Category Collection Name	`springline`	`categories_springline`

Dotdigital pairs a product collection with its categories by that shared base name. If the two settings are given different base names, products and categories both transfer successfully and nothing is recorded as an error, but the product's category references point at a collection that does not exist and the categories never resolve.

ID Format

Manual Sync ID — the iPaaS.com Product id (for example, 32134), entered on the iPaaS.com Manual Sync page when a product is transferred on demand.

External ID Format

After a successful transfer, iPaaS.com records the product's id as the Dotdigital record key, so later transfers of the same product update the existing record rather than creating a duplicate. Each variant is recorded under its own id combined with its parent product's id, joined by a vertical bar.

Product Types

The integration supports both ways a product can be sold, and selects the correct handling automatically from the product's tracking method:

Tracked at the product level: the product itself carries the SKU, price, and stock. No separate variant records are written.
Tracked at the variant level: the product record is written as a configurable product, and each variation is written separately through the child collection.

Deleted Record Support

Deleted records are not supported. This is an add-and-update flow: deleting a product, variant, or category in iPaaS.com does not remove the corresponding record from Dotdigital.

Note also that records are matched on their iPaaS.com id. A product deleted and recreated in the source system receives a new id and therefore transfers as a new Dotdigital record, leaving the original in place.

Custom Field Support

No custom field is required, and none is needed for standard product data.

Custom fields on products are supported only when Product Collection Type is set to custom, and choosing that type gives up participation in Dotdigital's native product features. Subscribers who need neither should use the catalog type. For how custom fields behave in general — including how a Dotdigital field name becomes the stored key, and why renaming a field starts a new key — see Dotdigital Transaction From iPaaS.com Mapping Documentation, which carries the integration's worked example.

Mapping Collection Status

Status — Enabled.

Trigger Events — Product Create and Update, enabled under Outbound Data Flows. No automatic transfers occur until those events are subscribed to.

Duplicate or Conflicting Mappings

There is no collision handling, because no other collection writes Dotdigital product records. Create-versus-update routing is handled within this collection by the product's id: an id that already exists updates the existing record, and a new id creates a new one. Each variant is matched the same way, on its own id combined with its parent product's id.

Supported Child Collections

Add/Update Dotdigital Variant FROM iPaaS.com — the product's variants. Variants are written only for products tracked at the variant level; a product tracked at the product level has none. They are read from the product and written as part of the same transfer, and there is no independent transfer path for a single variant.

Category Assignments

Assigning categories to products is optional, and a product transfers with or without them.

When categories are used, the integration prepares them before the product is written. For each category the product references it checks whether that category already exists in Dotdigital, transfers it first if not, and resolves the category's parent chain as it goes, so a category's parents are created before the category itself.

Two behaviours are worth planning around:

Categories that have not yet transferred are sent first, automatically. Before a product transfers, the integration checks each of its categories and transfers any that are not yet in Dotdigital, along with their parent chain, so a product does not need its categories synced ahead of it. If one of those category transfers fails, the product transfer stops and reports the error rather than landing with only some of its categories. The narrow exception is a category that cannot be read from iPaaS.com at all — one with no id, or whose record cannot be retrieved — which is skipped, and the product transfers without it.
Category assignments only accumulate. Removing a category from a product in iPaaS.com and re-transferring does not remove it from the product in Dotdigital.

System Caveats

Dotdigital Caveats

Product records are written to an account-level collection, not against individual contacts, so they are shared across the account rather than owned by a contact.
A collection's type is fixed when it is created and cannot be converted afterwards.
Dotdigital limits an account to 1000 Insight Data collections. Each product, category, and order collection counts toward that limit.

iPaaS.com Caveats

The product id is the record key, so re-syncing a product updates it rather than duplicating it, and a delete-and-recreate produces a new Dotdigital record.
Both collection-name settings are required before products can transfer, even when categories are not being assigned.

Setup Requirements

In Dotdigital, create an API user with permission to access the insight-data APIs.
In iPaaS.com, enter the Dotdigital API User and API Password.
In iPaaS.com, set Product Collection Type, and confirm the choice before the first transfer — it cannot be changed afterwards.
In iPaaS.com, set Product Collection Name and Product Category Collection Name to the same base name.
Under Outbound Data Flows, subscribe to the Product create and update events.

Integration Flow

An iPaaS.com Product is transferred, either automatically when a Product outbound trigger fires or on demand from the Manual Sync page.
The integration confirms the product collection named by the settings exists, creating it with the configured type if it does not.
If the product references categories, each one is checked and transferred first where needed, resolving parent categories ahead of their children.
The integration writes the product to the collection, keyed on the product's iPaaS.com id. An id that already exists updates the existing record; a new id creates a new one.
For a product tracked at the variant level, each variant is written as part of the same transfer.

Mappings

Add/Update Dotdigital Product FROM iPaaS.com

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

Mapping Type	Source Field (iPaaS.com)	Destination Field (Dotdigital)	Description
Dynamic Formula	Id	Id	Required. The product's identifier in Dotdigital, taken from the iPaaS.com product id. It is the record key, so it must be unique.
Field	Name	Name	Required. The product name, and what identifies the product in Dotdigital.
Field	Sku	Sku	Recommended. The product's stock-keeping unit, used to tie the product to orders and to other systems.
Field	DefaultPrice	Price	Recommended. The product's default price, used for product content and reporting.
Field	InStockThreshold	Stock	Recommended. The current stock threshold value.
Dynamic Formula	TrackingMethod	Type	Recommended. Whether the product is simple or configurable, derived from how the product is tracked so the correct type is set without configuration.
Field	SalePrice	SpecialPrice	Optional. The product's sale price, where one is set.
Dynamic Formula	Status	Status	Optional. Whether the product is enabled or disabled in Dotdigital, derived from the iPaaS.com product status.
Dynamic Formula	Categories	Categories	Optional. The categories the product belongs to, converted into the references Dotdigital stores. See Category Assignments above.

No mapping filter is applied to this collection.

Add/Update Dotdigital Variant FROM iPaaS.com

This is a child collection of Add/Update Dotdigital Product FROM iPaaS.com. Variants are read from the product and written together with it in a single operation; there is no independent transfer path for a single variant. There is no mapping filter applied: every variant of a processed product is sent with it.

Mapping Type	Source Field (iPaaS.com)	Destination Field (Dotdigital)	Description
Dynamic Formula	Variant id and parent product id	Id	Required. The variant's identifier in Dotdigital, built from the variant's own iPaaS.com id and its parent product's id joined by a vertical bar.
Dynamic Formula	ParentId	ParentId	Required. The product this variant belongs to, so Dotdigital records the variant against its parent.
Field	Sku	Sku	Recommended. The variant's stock-keeping unit. Each variation of a product carries its own.
Field	DefaultPrice	Price	Recommended. The variant's default price, which may differ from the parent product's.
Field	SalePrice	SpecialPrice	Optional. The variant's sale price, where one is set.
Static	`"Configurable"`	Type	Required. Marks the record as a variant of a configurable product. Leave it set to Configurable.