iPaaS.com Customer records are written out to Heartland as Heartland customers. iPaaS.com is the source in this direction and Heartland is the system being written to. The transfer writes core identity fields — first name, last name, and email address — to the Heartland customer, together with one Heartland custom field mapping supplied from the iPaaS.com side.

The template splits this outbound transfer into two parent collections: Add Heartland Customer FROM iPaaS.com creates a Heartland customer that does not yet exist, and Update Heartland Customer FROM iPaaS.com applies changes to a Heartland customer that is already linked. Each parent carries the customer's billing and shipping addresses to Heartland through its own child address collection, so a customer and its addresses always move in a single operation.

This article covers all four collections in this direction. The opposite direction — Heartland customers transferred into iPaaS.com — is handled by a separate set of collections and is documented separately.

The two parent collections are not alternatives a subscriber chooses between at transfer time; the integration selects one based on whether the iPaaS.com customer is already linked to a Heartland customer.

The two collections carry the same four mappings. The split exists so that update behavior can be controlled independently of create behavior: mappings can be removed or replaced in the Update collection to preserve Heartland values that should not be overwritten, without changing what is written when a customer is first created. The same split applies to the child address collections.

On the iPaaS.com Manual Sync page, enter the iPaaS.com customer's internal ID — for example, 145146. This outbound direction uses the iPaaS.com identifier, not a Heartland identifier. Transferring a customer this way also transfers that customer's addresses through the child collection.

After a successful transfer, the Heartland customer's unique identifier is saved in iPaaS.com as the external-id link between the two systems. The integration uses that link to locate the correct Heartland customer on every later transfer, so subsequent transfers update the same Heartland customer rather than creating a duplicate.

When an iPaaS.com customer is not yet linked, the integration searches Heartland for a customer with a matching email address before creating a new one. If a match is found, the external-id link is written for that existing Heartland customer and the transfer proceeds as an update.

Deleting a customer is not supported in this direction. The integration creates and updates Heartland customers only — deleting or deactivating a Customer record in iPaaS.com does not delete the linked Heartland customer. Customers that should no longer be active in Heartland must be managed directly in Heartland.

The same applies to addresses: removing an address from an iPaaS.com customer does not delete the corresponding Heartland address. The child address collections write addresses; they do not remove them.

This direction can write values to Heartland custom fields on the customer. Add a mapping whose destination is the Heartland custom field and whose source is the iPaaS.com value you want to write; at transfer time the integration sets that named Heartland custom field.

Prerequisite: a Heartland custom field must be created in Heartland manually before it is visible on the Heartland website and available as a mapping destination. Until the field exists in Heartland, a value mapped to it is not stored.

Both parent collections ship with a Test Customer Field mapping that writes the static value "Example values". This is a template example that demonstrates the pattern, not production configuration. Replace the value with the data you want to write and point the mapping at the Heartland custom field where it should be stored, or remove the mapping if it is not needed.

The child address collections have no trigger of their own. They run whenever their parent customer collection transfers a customer.

Four mapping collections operate on customer data in this outbound direction: the two parents described above and their two child address collections. Because the add and update paths are mutually exclusive for a given customer, the two parents never compete for the same record on the same transfer.

There is also an opposite direction. Add Heartland Customer TO iPaaS.com and Update Heartland Customer TO iPaaS.com, with their own child address collections, bring Heartland customers into iPaaS.com.

Important: before running both directions together, review your mapping collection filters and clearly define which system is the source of truth for customer data. If both directions are active with the default mappings, changes may propagate back and forth between the systems.

This integration does not use iPaaS.com collision handling for customers. Whether a customer is created or updated in Heartland is determined by the external-id link and, when that is absent, the email-address match; there is no collision recovery step to configure.

Each parent collection has exactly one child collection, and each child runs only as part of its own parent's transfer.

Neither child collection has a webhook, polling schedule, or Manual Sync entry of its own. An address reaches Heartland when its customer is transferred, and only then.

Heartland uses OAuth 2.0 to obtain an access token, which authorizes the Heartland API requests made during a transfer. Credentials are configured on the Heartland subscription — see the Heartland Installation Instructions.

Automatic outbound transfer (new customer):

Automatic outbound transfer (existing customer):

Unlinked customer matched by email:

Manual Sync:

Order transfer with an unlinked customer:

All paths converge on the same mapping logic, so the resulting Heartland customer is the same regardless of how the transfer was triggered.

Mapping Filter

This mapping collection does not have a mapping filter applied. All records routed to it are processed without additional filtering conditions.

Description: Creates a Heartland customer from an iPaaS.com Customer that is not yet linked to Heartland and has no Heartland match by email address. The parent of the Add/Update Heartland Customer Address FROM iPaaS.com child collection, which writes the customer's addresses in the same transfer.

This is a child collection of Add Heartland Customer FROM iPaaS.com. It does not transfer on its own and has no Manual Sync ID, webhook, or polling schedule of its own.

Mapping Filter

This mapping collection does not have a mapping filter applied. All records routed to it are processed without additional filtering conditions.

Description: Writes the iPaaS.com customer's billing and shipping addresses to the Heartland customer created or resolved by its parent collection. Its sync method is Add/Update: an address is created on the Heartland customer when it does not yet exist and updated in place when it does.

Mapping Filter

This mapping collection does not have a mapping filter applied. All records routed to it are processed without additional filtering conditions.

Description: Applies changes from an iPaaS.com Customer to the Heartland customer already linked to it, located through the saved external-id link. The parent of the Update Heartland Customer Address FROM iPaaS.com child collection, which writes the customer's addresses in the same transfer.

This is a child collection of Update Heartland Customer FROM iPaaS.com. It does not transfer on its own and has no Manual Sync ID, webhook, or polling schedule of its own.

Mapping Filter

This mapping collection does not have a mapping filter applied. All records routed to it are processed without additional filtering conditions.

Description: Writes the iPaaS.com customer's addresses to the linked Heartland customer as part of that customer's update, so the Heartland address records stay in step with iPaaS.com.

This direction writes to Heartland, and the transfer sends a partial payload built from the mapped values. As a result, Heartland fields that these collections do not map are generally not cleared on update — the behavior is not the full-replace behavior that applies when records are written into iPaaS.com. Two qualifications matter, and both are subscriber-visible.

Every mapped field is overwritten on update. For the customer itself, the first name, last name, email address, and the mapped Heartland custom field are replaced with the incoming iPaaS.com values each time the Update Heartland Customer FROM iPaaS.com collection runs. If Heartland is where any of those values is maintained, edits made there will be written over on the next outbound transfer. Remove or re-point the mapping in the Update collection for any field you want Heartland to own.

Specific Heartland address fields can be cleared on update. When an existing Heartland customer address is updated, the following Heartland address fields are not written by either address collection and can be cleared:

If your integration relies on any of these on the Heartland side, do not assume they survive an update.

Preservation remedy. The template deliberately splits the transfer into separate Add and Update collections so that update behavior can be controlled. In the Update collection, add a Dynamic Formula mapping whose source is DestinationValue.[FieldName] for each Heartland field you need to keep. That reads the current Heartland value and writes it back, so the field is not cleared.

Validate in staging. Partner-side clearing behavior should be confirmed rather than assumed. Before enabling outbound updates in production, run an update against a Heartland customer in a staging environment that has values in the fields listed above and in any Heartland field you care about, and confirm afterward which values survived. Add preservation mappings for anything that did not.

Setup & Reference

Mapping Documentation