Clover customers can be transferred into iPaaS.com so that the iPaaS.com customer list stays aligned with the customers who exist in Clover. Two parent collections carry the flow: one creates new iPaaS.com customers from Clover and one updates customers that already exist, each with a child collection that carries the customer's address alongside the customer record. Customers move automatically as part of transaction polling — when the integration polls a Clover order that references a customer, that customer is transferred with the order — and Manual Sync is always available to transfer a specific customer on demand.

The parent customer collections accept a Manual Sync key. Enter the Clover customer identifier for the customer you want to transfer. A Clover customer identifier is a single opaque value carried on the customer record.

The two child address collections do not take their own Manual Sync key. An address is matched to its customer through the parent transfer, so there is no separate identifier to enter for the address.

After a customer transfers, the integration stores a dedicated external-identifier record that links the Clover customer to its iPaaS.com counterpart, keyed on the Clover customer identifier. Because of this link, the same Clover identifier resolves the same iPaaS.com record on every repeat transfer, so re-syncing a customer updates the existing record rather than creating a duplicate.

Outbound delete is not part of this flow. The Add and Update collections documented here transfer new and changed customers into iPaaS.com; they do not carry deletions. Delete mappings are not included in the default templates for the Clover-to-iPaaS.com customer collections, and a customer removed in Clover is not automatically removed from iPaaS.com through these collections. If a customer should no longer be active in iPaaS.com, manage that customer directly in iPaaS.com.

Status: Both parent collections are active. Add Clover Customer TO iPaaS.com creates customers; Update Clover Customer TO iPaaS.com updates existing customers. Each processes a Clover customer only when the customer passes the mapping filter described in the Mappings section. The two child address collections are active and have no filter of their own.

Trigger Events: A customer is transferred when a polled Clover order references that customer (the customer travels with the transaction). Manual Sync can trigger a transfer of a specific customer at any time. No webhook configuration is required by the subscriber.

Two collections target the Clover-sourced iPaaS.com customer: one creates and one updates. To avoid records overwriting one another, no other active mapping collection should target the same iPaaS.com customer from the same source. Review your active collections if the same customer appears to change unexpectedly.

The Clover integration does not provide collision handling for the customer flow. When the same record could be changed from more than one side, the integration does not run a field-level merge or conflict-resolution step. Decide which system is the system of record for each customer and drive changes from that side. This behavior is described in the Clover Integration Known Limitations article.

The Update flow writes the mapped fields onto the existing iPaaS.com customer on every transfer. First Name, Last Name, and Email Address are refreshed from Clover each time, so any value entered directly in iPaaS.com on those fields is replaced by the Clover value on the next update. The integration omits empty (null) values from the write rather than sending them as blanks, so a field that is not part of these collections' mappings is left as it is on the destination record — unmapped fields are preserved, not cleared. For a field that should keep a value set in iPaaS.com rather than one sourced from Clover, use the destination-value approach so the update reads the existing iPaaS.com value back into the write and preserves it. This is exactly how Customer Number is preserved on update, using DestinationValue.CustomerNumber.

Each parent customer collection supports one child address collection. The child does not transfer on its own; it moves whenever its parent customer moves.

When Clover reports that too many requests have been made in a short period, the integration automatically pauses and retries the affected calls; no subscriber action is required. Customer records that have no email address in Clover are excluded by the mapping filter and will not appear in — or be updated in — iPaaS.com. For the address child collections, only address fields that are present on the Clover customer are carried; a field that is empty in Clover arrives empty in iPaaS.com.

iPaaS.com treats Customer Number as the primary customer identifier and expects a value on every record; on update the existing number is preserved rather than replaced. Email Address is expected to be unique per customer — if a Clover customer resolves to an email that already exists on a different iPaaS.com customer, the transfer can be rejected as a conflict. An address is stored against the customer created or matched by the parent collection: if the parent customer is not created or matched, there is no customer to attach the address to and the address is not stored.

The guest-email default is the only conditional field behavior in this flow. When a Clover customer's email is empty, the collection substitutes the default value guest@customerdomain.com so the required Email Address field is satisfied. Because the mapping filter already skips customers whose Clover email is empty, this default acts as a safeguard rather than the usual outcome. Note that multiple customers resolving to the shared guest value can conflict with one another under the uniqueness expectation above.

Populate an email address on each Clover customer you expect to sync; customers with no email are excluded by the filter. Populate the customer's address fields where available so the address child collection has data to carry.

No subscriber-facing setup is required on the iPaaS.com side to receive customers — automatic capture happens as part of transaction polling, so there is no webhook to configure. The Clover integration must be installed and authorized for the subscription before any transfer, and for the update flow a matching customer must already exist in iPaaS.com for the update to apply.

The integration authenticates to Clover using the credentials established when the Clover integration is authorized for the subscription. No additional per-transfer authentication is required for the customer flow. For the full installation and authorization walkthrough, see the Clover Installation Instructions article.

The Add and Update parent collections carry the same four customer fields, differing only in how Customer Number is handled (created from Clover on Add; preserved from the existing record on Update). The two child collections carry the same eight address fields. Each is documented below.

iPaaS.com data type: Customer

Mapping Filter

Filter Description. This collection processes a Clover customer only when the customer has a non-empty email address. A customer whose Clover EmailAddress is empty fails the filter and is skipped — no iPaaS.com customer is created and no error is raised (the skip is silent). The filter is evaluated against the raw Clover email before the email mapping's default guest value is applied, so an empty-email customer is never created even though the email mapping could otherwise supply a default.

iPaaS.com data type: Customer

Mapping Filter

Filter Description. This collection processes a Clover customer only when the customer has a non-empty email address. A customer whose Clover EmailAddress is empty fails the filter and is skipped — the existing iPaaS.com customer is not updated and no error is raised (the skip is silent). As with the Add collection, the filter is evaluated against the raw Clover email before the email mapping's default guest value is applied.

iPaaS.com data type: Customer Address

This child collection has no mapping filter of its own. Its records are gated entirely by the parent Add Clover Customer TO iPaaS.com collection: whichever customers the parent processes, their addresses are carried through here. The address transfers only as part of the parent customer transfer.

iPaaS.com data type: Customer Address

This child collection has no mapping filter of its own. Its records are gated entirely by the parent Update Clover Customer TO iPaaS.com collection: whichever customers the parent updates, their addresses are carried through here. The address update transfers only as part of the parent customer update. Because these fields are refreshed from Clover on every update, a value edited directly in iPaaS.com on a mapped address field is replaced by the Clover value on the next transfer, and an empty source field clears the mapped destination field.

Errors for this flow surface in the iPaaS.com Dashboard under Integration Monitoring and then Error Logs. The full catalog of Clover integration error messages, with resolutions, lives in the Clover Error Messages article; consult it when you see an error in your logs.

Two behaviors specific to the customer flow are worth calling out: