Summary
Customer records are transferred from Adobe Commerce/Magento 2 into iPaaS.com. Each Magento customer becomes one iPaaS.com Customer carrying the customer number, first and last name, and email address, and a child collection brings the customer's addresses across as part of the same transfer.
Shoppers who register or are created in the storefront become Customers in iPaaS.com, so downstream systems connected through iPaaS.com work from the same customer master.
This is the inbound direction. A separate outbound family writes customers from iPaaS.com into Magento; see Duplicate or Conflicting Mappings below for what enabling both means.
ID Format
Manual Sync ID Format
Enter the Adobe Commerce/Magento 2 customer id — the internal numeric identifier of the customer record, for example 4417.
The customer's email address is not accepted as a Manual Sync value.
External ID Format
After a successful transfer, iPaaS.com stores the Adobe Commerce/Magento 2 customer id as the external ID on a record linking the Magento customer to the iPaaS.com Customer. That record routes later transfers of the same customer to the existing Customer for an update rather than creating a duplicate.
It is also what the order family's prerequisite handling looks for when it checks whether an order's customer already exists in iPaaS.com.
Deleted Record Support
Outbound delete is not supported in this direction. Removing a customer in Adobe Commerce/Magento 2 does not remove the corresponding iPaaS.com Customer, and delete mappings are not included in the default templates for this family.
An address removed in Magento is likewise not removed from iPaaS.com by the address child.
Custom Field Support
Neither collection reads or writes a custom field. Every value comes from a standard field on the Magento customer or address record.
Mapping Collection Status
Status: Enabled. Both collections ship enabled.
Trigger Events: Creation or update of a customer in Adobe Commerce/Magento 2, plus Manual Sync on demand. A customer is also transferred automatically as a prerequisite when an order belonging to that customer is transferred.
Adobe Commerce/Magento 2 has no native webhook capability, so automatic transfers depend on the third-party webhook extension being installed and configured in the Magento store. There is no scheduled polling of Magento customers — changes arrive when the extension raises the event, when a Manual Sync is run, or when an order pulls the customer through as a prerequisite.
Duplicate or Conflicting Mappings
Add/Update Adobe Commerce/Magento 2 Customer FROM iPaaS.com and its address child move customer data in the opposite direction, from iPaaS.com into Magento. They are the outbound counterparts of these collections rather than competitors for the same write.
Subscribers or their MiSP who enable both directions should be aware that customer data then round-trips between the two systems, and should decide which system is the master for each field so a value maintained in one is not replaced by the other on the next transfer.
Add/Update Adobe Commerce/Magento 2 Standalone Customer Address FROM iPaaS.com writes addresses outbound without a customer transfer above it, and can therefore change the same addresses this family reads.
Duplicate matching
This integration implements no selectable collision-handling methods, and the behavior is not configurable on these collections. The external-ID record linking the Magento customer to its iPaaS.com Customer decides whether a transfer creates or updates.
Where no link exists, the integration also attempts to match an existing iPaaS.com Customer by email address and create the link rather than producing a duplicate. A Magento customer whose email address duplicates an existing iPaaS.com Customer that cannot be linked is rejected rather than merged.
Unmapped field overwrite risk
When a customer is re-transferred, the mapped values are written again over the existing iPaaS.com Customer. The fields at risk are CustomerNumber, FirstName, LastName and EmailAddress on the customer, and FirstName, LastName, Address1, Address2, Address3, City, Region, Country, PostalCode, IsPrimaryBilling and IsPrimaryShipping on each address.
Values edited directly in iPaaS.com on any of those will be replaced by the Magento value on the next transfer. This matters most where the outbound direction is also enabled, since the two families then write the same fields from opposite sides.
The mitigation is a DestinationValue. Where an iPaaS.com field must hold a specific value that the Magento customer does not supply, set a DestinationValue on that mapping so the integration writes the value chosen there instead of taking it from the source. Values that must be maintained only in iPaaS.com should be kept on fields these collections do not map.
Supported Child Collections
The parent collection is Add/Update Adobe Commerce/Magento 2 Customer TO iPaaS.com. It has one child:
Add/Update Adobe Commerce/Magento 2 Customer Address TO iPaaS.com: brings the customer's addresses into iPaaS.com as part of the customer's transfer. It runs beneath the parent and does not transfer on its own schedule.
System Caveats
Adobe Commerce/Magento 2 Caveats
The street is a multi-line list. Magento stores the street portion of an address as a list rather than a single field, and the mappings take the first three lines individually. Street detail beyond three lines is not carried.
The region is a structured object. Magento holds both a short region code and a full region name on an address; this family carries the full region name.
Webhook capability requires a third-party extension. Magento does not provide webhooks natively, and there is no scheduled polling, so without the extension customers arrive only through Manual Sync or as an order prerequisite.
Customer retrieval is subject to Magento's API limits. A large initial customer load can encounter request-array and page-size limits. Stagger large manual catch-up runs rather than issuing them concurrently.
iPaaS.com Caveats
The email address is required. It is the value the duplicate-matching fallback uses, and an iPaaS.com Customer cannot be written without it.
A duplicate email is rejected, not merged. Where an existing iPaaS.com Customer already holds the incoming email address and cannot be linked, the transfer of that customer fails rather than combining the two records.
Addresses arrive only with their customer. An address edited in Magento without any other customer change may not reach iPaaS.com until the next customer transfer or Manual Sync.
Integration-Specific Caveats
Address removals do not propagate. An address deleted in Magento remains on the iPaaS.com Customer.
Enabling both directions creates a round trip. The outbound customer family writes the same fields from iPaaS.com into Magento. Decide field-by-field which system is master before enabling both.
This family is also a prerequisite path. When an order is transferred for a customer that iPaaS.com does not yet hold, the order transfer pulls the customer through this collection first, and a failure there blocks the order.
Setup Requirements
Adobe Commerce/Magento 2 Configuration
Install and configure the third-party webhook extension and subscribe it to the customer events, if customers should transfer automatically.
Confirm customer email addresses are populated and unique.
iPaaS.com Configuration
Decide which system is the master for customer data, and enable the outbound customer family only if a round trip is intended.
Confirm the address child is enabled if addresses are needed alongside customers.
Enable the inbound flow for Adobe Commerce/Magento 2 customers on the subscription's Inbound Data Flows page.
Full step-by-step setup instructions are in the Adobe Commerce/Magento 2 Installation Instructions article, and the webhook extension setup is covered in Configure Mageplaza Webhooks for iPaaS.com.
Integration Flow
A customer is created or updated in Adobe Commerce/Magento 2, or a Manual Sync is run, or an order transfer pulls the customer through as a prerequisite.
The customer is evaluated by the parent collection. It carries no filter, so every customer received is processed.
iPaaS.com decides between an Add and an Update using the external-ID record, falling back to an email-address match where no link exists.
The customer header is written, carrying the customer number, name and email address.
The address child runs against the customer's addresses and writes each one onto the same iPaaS.com Customer, including the primary billing and primary shipping flags.
Mappings
Add/Update Adobe Commerce/Magento 2 Customer TO iPaaS.com (Parent)
iPaaS.com data type: Customer
This collection carries no mapping filter — every Magento customer record received is processed.
Mapping Type | Source Field (Adobe Commerce/Magento 2) | Destination Field (iPaaS.com) | Description |
Field | Id | CustomerNumber | Required. The Magento internal customer id, carried as the customer number on the iPaaS.com record. |
Field | EmailAddress | Required. The customer's email address. Also the fallback match used to link an incoming customer to an existing iPaaS.com Customer where no external-ID record exists. | |
Field | FirstName | FirstName | Recommended. The customer's first name. |
Field | LastName | LastName | Recommended. The customer's last name. |
Add/Update Adobe Commerce/Magento 2 Customer Address TO iPaaS.com (Child)
iPaaS.com data type: Customer Address
This collection carries no mapping filter. Every address on the transferring customer is processed.
Mapping Type | Source Field (Adobe Commerce/Magento 2) | Destination Field (iPaaS.com) | Description |
Dynamic Formula |
| Address1 | Recommended. The first street line from Magento's multi-line street list, or an empty string when the street is empty. |
Dynamic Formula |
| Address2 | Recommended. The second street line, typically a suite, unit, or apartment. Expected to be blank for single-line addresses. |
Dynamic Formula |
| Address3 | Recommended. The third street line. Expected to be blank for most addresses. |
Field | City | City | Recommended. The address city. |
Dynamic Formula |
| Region | Recommended. The full region name from Magento's structured region object, rather than the short region code. |
Field | CountryId | Country | Recommended. Normally the two-letter country code, for example US. |
Field | PostCode | PostalCode | Recommended. The address postal code. |
Field | FirstName | FirstName | Recommended. The address contact's first name. |
Field | LastName | LastName | Recommended. The address contact's last name. |
Field | DefaultBilling | IsPrimaryBilling | Recommended. Marks the address as the customer's primary billing address, from the Magento default-billing flag. |
Field | DefaultShipping | IsPrimaryShipping | Recommended. Marks the address as the customer's primary shipping address, from the Magento default-shipping flag. |
Error Handling
The full catalog of messages this integration produces, with causes and resolutions, is in the Adobe Commerce/Magento 2 Error Messages article. The conditions most often seen on this transfer are:
An existing iPaaS.com customer could not be linked by email. A customer with the same email address already exists in iPaaS.com and the link could not be created, which risks duplicate customer records. Resolution: reconcile the duplicate in iPaaS.com, then re-run the customer.
A customer rejected for a missing email address. Resolution: populate the email address in Magento and re-run.
An order blocked by its customer prerequisite. The order's customer could not be created in or linked to iPaaS.com, which stops the order transferring. Resolution: resolve the customer first, then re-sync the order.
Errors are reported under Dashboard / Integration Monitoring / Error Logs.
Testing & Validation
Test Scenarios
Register a customer in the Magento storefront and confirm an iPaaS.com Customer is created with the correct customer number, name and email address.
Manually sync using the Magento customer id and confirm it resolves; confirm the email address does not.
Update the customer's name in Magento and confirm the same iPaaS.com Customer is updated rather than a duplicate created.
Add two addresses to the customer, one default billing and one default shipping, and confirm both arrive with the correct primary flags.
Enter a three-line street in Magento and confirm all three lines arrive on the iPaaS.com address.
Confirm the region arrives as the full region name rather than the short code.
Create a Magento customer whose email address matches an existing iPaaS.com Customer, and confirm the behavior — linked, or rejected — before go-live.
Delete an address in Magento, re-transfer the customer, and confirm the address remains in iPaaS.com.
Place an order for a customer that iPaaS.com does not yet hold, and confirm the customer is transferred automatically before the order lands.
If the outbound customer family is also enabled, change the same field on both sides and confirm which system wins.
Validation Checklist
Customer email addresses are populated and unique in Magento.
The address child is enabled if addresses are required.
The webhook extension is configured for customer events, or the team accepts that customers arrive only by Manual Sync and as order prerequisites.
A decision has been recorded on which system is master for customer data, if both directions are enabled.
The duplicate-email behavior has been observed in staging.
Additional Notes
There is no scheduled polling of Magento customers. Changes arrive by webhook event, Manual Sync, or as an order prerequisite.
Address removals and customer removals do not propagate to iPaaS.com.
Only the first three street lines are carried.
Validate the duplicate-email behavior and, where both directions are enabled, the round-trip behavior in a staging environment before enabling automatic transfers in production.