These are the known limitations of the Clover integration. They are inherent to the current design of the integration and to the capabilities of the Clover Platform REST API, and they apply to all subscribers. Each limitation is described as it stands at the time this documentation was written; framing them here sets clear expectations before you configure a transfer and points you to a next step where one exists.
Platform Scope and Tested Versions
The Clover integration is built for the Clover point-of-sale platform through the Clover Platform REST API v3. It communicates with the Clover REST API using the Environment URL configured on the subscription (the Clover sandbox base URL for testing, or the production base URL for live merchants).
At the time this documentation was written, the integration was last tested end-to-end against a Clover merchant sandbox on 2026-07-06. Clover exposes a stable, versioned public API (v3), and the integration is built against that documented version.
Not built for. This integration is scoped to Clover's merchant/e-commerce REST API (customers, orders, and the product catalog) and nothing else:
Clover Gift Cards are out of scope for this release. Gift card flows are not transferred by any collection.
Other Clover product lines or developer surfaces (for example, hardware-device or app-marketplace APIs beyond the merchant REST API) are not in scope.
Non-Clover point-of-sale or commerce platforms are not supported. This integration cannot be pointed at another vendor's system.
If Clover launches a separate product line, or a materially different API generation in the future, this integration will not automatically support it until it is explicitly updated.
1. Unmapped Field Overwrite Risk on Add/Update transfers
At the time this documentation was written, the Add/Update flows that write records — the Customer and Transaction transfers — write the full record on every transfer rather than patching individual fields. Fields that are included in the mapping are written on each transfer. Fields that are not mapped are left as they are on the destination record: the integration omits empty (null) values from the write instead of sending them as blanks, so an unmapped field is preserved rather than cleared.
What this means for you. For any field that is part of the mapping, the source system is the source of truth: a value edited directly on the destination record is replaced by the source value on the next transfer. Unmapped fields are safe — they are not blanked. If you have a field that should keep its destination value and never be overwritten by the source, subscribers or their MiSP can set that field's mapping to use the DestinationValue function (for example DestinationValue.CustomerNumber), which reads the existing destination value back into the write so the transfer preserves it. This is the recommended mitigation whenever a field must survive re-transfers unchanged.
Note: This applies to the fields carried by the Customer and Transaction Add/Update collections and their address children. Review each collection's mapping to see exactly which fields are in scope; anything not listed is not written and is therefore preserved.
2. Collision handling is not offered
At the time this documentation was written, the Clover integration does not provide collision handling. When the same record could be updated from more than one side, the integration does not run a field-level merge or conflict-resolution step to reconcile competing changes.
What this means for you. Decide which system is the system of record for each entity and drive changes from that side. Because mapped fields follow the source on every transfer (see Limitation 1), letting both sides edit the same mapped field independently can cause the value to flip back and forth on successive transfers. If your workflow needs automatic conflict resolution between the two systems, subscribers or their MiSP can submit a feature request through your iPaaS.com partner channel describing the specific reconciliation behavior you need; input like this informs future enhancement releases.
3. Order duplicate handling requires manual attention
At the time this documentation was written, transferring an order into Clover can, in some cases, produce a duplicate order for the same source reference rather than reconciling to the existing one. When this happens, the integration removes the open duplicate and reports a condition indicating that one or more unopened duplicate orders exist and that manual intervention is required to resolve them.
What this means for you. If an order transfer reports a duplicate-order condition, open Clover and check the affected order for that source reference before re-running the transfer, and resolve any unopened duplicate that Clover still shows. Validate the create-and-repeat and update-and-repeat behavior in a staging environment before relying on it in production, so you know how duplicates present for your merchant configuration. When a transfer surfaces this condition, review it in Dashboard / Integration Monitoring / Error Logs and act on the flagged order rather than blindly retrying.
Note: This applies to the inbound order flow (orders written into Clover). Order transfers out of Clover are not affected.
4. Product option-definition updates and catalog deletions
At the time this documentation was written, the outbound (FROM iPaaS.com) catalog transfer creates the full product structure in Clover — simple products, product variants within an item group, option groups, option values, variant option assignments, and both product and per-variant inventory. Product and variant stock quantities are also updated on existing Clover items, so inventory adjustments made in iPaaS.com are reflected in Clover.
Two behaviors are limited in the current release. First, option groups, option values, and variant option assignments are created — or matched to an existing one — the first time they are transferred, but they are not updated afterward: changing an option group's or option value's definition in iPaaS.com after it already exists in Clover does not push that change to the existing Clover option. Second, deletions are not propagated to Clover — removing a product, variant, or option in iPaaS.com does not remove the corresponding record from the Clover catalog.
What this means for you. Product and inventory synchronization, including variant builds and stock adjustments, work on the outbound path. If you need to change an option definition after it has been created in Clover, or to remove a catalog record from Clover, make that change directly in Clover, because the integration does not push option-definition updates or deletions. Validate your specific catalog structure in a staging environment before relying on it in production. If ongoing option-definition updates or delete propagation are important to your workflow, subscribers or their MiSP can submit a feature request through your iPaaS.com partner channel.
Note: Fractional stock is floored to a whole number, and stock is retained in Clover only on items that have stock tracking enabled — enable Track Stock on the target Clover items so stock values persist.
5. Guest-email default for customers without an email
At the time this documentation was written, a customer without an email address is handled differently by direction. Inbound to iPaaS.com, a Clover customer with no email is filtered out and no partial contact is created. Outbound to Clover, a customer with no email is written with a shared default address, guest@customerdomain.com, so the Clover write is not rejected for a missing email.
What this means for you. Because the outbound default is a single shared address, several email-less customers can resolve to the same default contact rather than to distinct records. To keep customers distinct, subscribers or their MiSP should provide a real, unique email address on each customer before transfer wherever possible. Validate the email-less behavior in a staging environment before relying on it in production, so you understand how your merchant's records consolidate.
Placeholder value — replace during implementation: the customerdomain.com portion of the guest@customerdomain.com default is an example domain, not a domain iPaaS.com or Clover owns. Replace it in the outbound customer EmailAddress mapping with a domain your organization controls (for example, guest@yourbusiness.com) so the fallback emails for email-less customers are recognizable and stay under a domain you own.
Note: The inbound filter means email-bearing Clover customers transfer normally; the guest default only applies on the outbound write, and only when the source email is empty.
6. Notes, order lines, and fixed field values
At the time this documentation was written, a small number of fields are set to fixed values or scoped to a subset of data by design:
Notes transferred to a Clover order are limited to public notes; private notes are not transferred.
Order lines written into Clover link to a Clover catalog item only when the line's item code matches an existing Clover item; when there is no match, the line is written without a catalog link.
Some destination fields on outbound order lines, payments, and the billing address are recorded as fixed values (for example, the billing address country is recorded as United States) rather than read from the source order.
A Clover order line with a zero quantity is recorded on the iPaaS.com transaction as a quantity of one.
Inbound to iPaaS.com, only completed (paid) Clover orders are transferred; orders in other payment states do not transfer.
What this means for you. Review the relevant mapping collection description before go-live so you know which fields are fixed and which subset of data is in scope, and validate the results in a staging environment. If a fixed value or a scoped subset does not fit your workflow, subscribers or their MiSP can submit a feature request through your iPaaS.com partner channel describing the behavior you need; input like this informs future enhancement releases.
7. No bulk historical import on first connect
At the time this documentation was written, the Clover integration does not perform a bulk historical import when it is first connected. Existing records are not back-filled on initial connection — initialization is disabled on every model — so records are not loaded in bulk. Instead, they synchronize going forward as transactions are polled and as outbound data flows dispatch records.
What this means for you. On a new connection, do not expect your existing Clover or iPaaS.com history to appear automatically; only records that change or are created after the integration is connected synchronize on their own. Subscribers or their MiSP who need to move a large existing dataset should use the supported bulk sync using Postman workflow to load that history, after which going-forward records synchronize automatically.
Note: This applies on initial connection and to all models in the integration; there is no separate setting to enable a one-time historical back-fill.
This document covers seven known limitations of the Clover integration. For the field-level detail behind each one — exactly which fields a collection maps, what is out of scope for that collection, and the prerequisites for each transfer — see the Clover mapping collection descriptions.