Summary
BigCommerce customers and their addresses transfer to iPaaS.com. Inbound transfers capture new and changed BigCommerce customers, and the addresses on them, into iPaaS.com Customer and Customer Address records. Transfers run automatically from subscribed BigCommerce webhook events or on demand from the iPaaS.com Manual Sync page.
This article covers the standard (non-B2B) inbound customer collections. Customers, companies, and users belonging to BigCommerce B2B Edition are handled by a separate set of collections — see the Related Documents footer. Writing iPaaS.com customers and customer categories out to BigCommerce is covered by the companion iPaaS.com to BigCommerce Customer Mapping Documentation. Only one of the B2C (standard) or B2B mappings should apply to any given customer.
Contents
Data Types and Direction
This article documents the following mapping collections and the iPaaS.com data type each one operates on. Every collection here transfers BigCommerce to iPaaS.com.
Collection | iPaaS.com data type | Direction |
Add BigCommerce Customer TO iPaaS.com | Customer | BigCommerce to iPaaS.com |
Update BigCommerce Customer TO iPaaS.com | Customer | BigCommerce to iPaaS.com |
Add BigCommerce Customer Address TO iPaaS.com (child) | Customer Address | BigCommerce to iPaaS.com |
Update BigCommerce Customer Address TO iPaaS.com (child) | Customer Address | BigCommerce to iPaaS.com |
Add BigCommerce Customer Address TO iPaaS.com (standalone) | Customer Address | BigCommerce to iPaaS.com |
Update BigCommerce Customer Address TO iPaaS.com (standalone) | Customer Address | BigCommerce to iPaaS.com |
ID Format
Manual Sync IDs differ by collection because each collection acts on a different record. Enter the ID that matches the collection you are syncing.
Manual Sync ID Format
Customer: enter the BigCommerce customer ID — the numeric identifier BigCommerce assigns to the customer. Example: 123.
Customer Address (standalone): enter the BigCommerce customer address ID — the numeric identifier BigCommerce assigns to the address. Example: 456.
Addresses transferred as part of a customer have no independent Manual Sync entry point; sync the parent customer and its addresses transfer together.
External ID Format
After a successful transfer, iPaaS.com records the BigCommerce identifier as the external ID on a dedicated external-ID record for the transferred record:
For a customer captured into iPaaS.com, the BigCommerce customer ID is saved as the external ID, and the BigCommerce customer ID is also written to the Customer's CustomerNumber field. The external-ID record is the primary match that routes later transfers to an update; CustomerNumber serves as a fallback match key when no external-ID record yet exists.
For a standalone address captured into iPaaS.com, the BigCommerce customer address ID is saved as the external ID on the Customer Address.
The external-ID record is the match that routes later transfers of the same record to an update rather than creating a duplicate.
Deleted Record Support
Outbound delete is not supported for these collections. Delete mappings are not included in the default templates, and deleting a customer or address in BigCommerce does not propagate the deletion to iPaaS.com. Remove records manually in each system as needed.
Custom Field Support
BigCommerce does not expose custom fields for the customer or customer address data types, and no iPaaS.com custom fields are created by default for these records. No custom-field configuration is required to run the inbound customer collections.
Mapping Collection Status
All collections in this article ship Enabled. Trigger events:
Customer and child addresses: BigCommerce customer created and customer updated events.
Standalone addresses: the standalone address collections also respond to BigCommerce customer address events.
Whether a given event drives an Add or an Update depends on whether the record is already linked to iPaaS.com by an external ID. Automatic transfers do not run until the corresponding events are subscribed — see Setup Requirements.
Duplicate or Conflicting Mappings
Several collections operate on the same underlying records. Review their filters and Add/Update settings before enabling them, and decide which collection is the source of truth for each record.
Standard vs. B2B customers. The inbound customer filter splits customers between the standard collections documented here and the separate B2B collections. Only one of the standard or B2B mappings should apply to any given customer. Enabling both without coordinated filters can create duplicate or conflicting customers.
Add vs. Update. The inbound Customer path is split into an Add collection and an Update collection. The external-ID link decides which one applies to a given event.
Child address vs. standalone address. An address can be captured either as part of a full customer transfer (the address child collections) or on its own (the standalone address collections). Confirm each collection captures a distinct set of addresses so the same address is not written twice.
Collision Handling
The Customer data type matches on email address. When iPaaS.com finds an existing Customer with the same email, the two records are assumed to be the same customer, and the transfer updates the existing record rather than creating a duplicate.
The behavior on a match is configurable on the mapping collection. The selectable methods are:
Remap and Link: link the incoming record to the matched record and remap it.
Update and Link: update the matched record and keep the link.
Update and No Link: update the matched record without establishing a persistent link.
Error: stop and raise an error instead of resolving the match automatically.
Choose the method that fits how your business wants duplicate emails handled before enabling the collection. A customer without an email cannot be matched reliably.
Customer Address does not use email collision handling. Duplicate addresses are controlled by the PreventDuplicate mechanism (see the address collections in the Mappings section).
Supported Child Collections
The inbound Customer collections drive their addresses through child collections that transfer as part of the customer:
Add BigCommerce Customer TO iPaaS.com → Add BigCommerce Customer Address TO iPaaS.com
Update BigCommerce Customer TO iPaaS.com → Update BigCommerce Customer Address TO iPaaS.com
The standalone Customer Address collections (Add and Update) are not children of the customer transfer — they capture and link an address directly to an already-transferred iPaaS.com Customer. Customer Address is a leaf collection with no children of its own.
System Caveats
BigCommerce Caveats
Duplicate customers allowed. BigCommerce B2C permits duplicate customers to be created. Rely on email matching (see Collision Handling) to avoid creating duplicates.
Channel association. A customer can be associated with one or more BigCommerce channels, and those channel assignments are carried to iPaaS.com. On an inbound update, incoming channel assignments are merged with the channels already recorded on the iPaaS.com Customer so existing assignments are preserved.
Rate limiting. When BigCommerce rate-limits requests, the transfer is automatically rescheduled to resume after the limit window resets. No subscriber action is required.
iPaaS.com Caveats
Email required for matching. The email address is the key iPaaS.com uses to match and de-duplicate customers. A customer without an email cannot be matched reliably.
Parent Customer required for addresses. An address is captured only in relation to its parent Customer. For child address collections, the parent customer must transfer for its addresses to be processed. For the standalone address collections, the linked iPaaS.com Customer must already exist for the address link to resolve.
Integration-Specific Caveats
PreventDuplicate scope. The duplicate-address suppression described in the address collections applies only to addresses transferred as a subcollection of a full customer request. Standalone address-only transfers do not honor PreventDuplicate.
Setup Requirements
Automatic transfers do not run until the corresponding events are subscribed. Configure the BigCommerce customer webhooks and enable the corresponding events under Inbound Data Flows in the subscription configuration. The standalone address collections also require the BigCommerce customer address events. See the Installation Instructions for the webhook setup steps.
Integration Flow
Customer and its addresses:
A BigCommerce customer created or updated event fires, or a customer is manually synced by its BigCommerce customer ID.
The inbound filter routes standard customers here and skips B2B company users.
iPaaS.com matches the incoming customer to an existing Customer on email address (see Collision Handling). A match updates the existing Customer; no match creates a new one.
Each address on the customer is captured through the child address collection and linked to the Customer.
Standalone address:
A BigCommerce customer address event fires, or an address is manually synced by its BigCommerce customer address ID.
The address is matched to its iPaaS.com Customer through the CustomerId link; the Customer must already exist in iPaaS.com.
A new address is created; an existing address (matched by its external-ID record) is updated.
Mappings
Each collection below lists its Mapping Filter (when the collection has one), the iPaaS.com data type it operates on, and its field mapping table. Source and destination field names are shown as they appear in each system.
Add / Update BigCommerce Customer TO iPaaS.com
iPaaS.com data type: Customer
The Add and Update collections are nearly identical: both capture a BigCommerce customer into an iPaaS.com Customer. Add handles new customers; Update handles changes to a customer that already exists in iPaaS.com. The two differences are noted in the field table.
Mapping Filter
if(B2B_UserIdFromB2B == null) return true;return false;
Filter Description. A customer is processed here only when it is not a B2B company user — that is, when it has no B2B user identifier (B2B_UserIdFromB2B is null). Customers that carry a B2B user identifier are skipped and handled by the B2B Customer collections instead. This filter contains no environment-specific value, so no placeholder substitution is required.
Mapping Type | Source Field (BigCommerce) | Destination Field (iPaaS.com Customer) | Description |
Field / Dynamic Formula |
| CustomerNumber | Required. On Add, stores the BigCommerce customer ID on the Customer; it provides visibility and acts as a fallback match key when no external-ID link yet exists. On Update, preserves the customer's existing iPaaS.com customer number by carrying it forward rather than overwriting it. |
Field |
| EmailAddress | Required. The customer's email, and the key iPaaS.com matches on to de-duplicate customers (see Collision Handling). |
Field |
| FirstName | Recommended. The customer's first name. |
Field |
| LastName | Recommended. The customer's last name. |
Field |
| Company | Recommended. The customer's company name where present. |
Field |
| Comment | Recommended. The customer's notes, carried to the Customer's comment field. |
Dynamic Formula |
| Channel Assignments | Recommended. Records the BigCommerce channels the customer is associated with as a comma-separated list of channel IDs. On Add, defaults to channel |
Add — Channel Assignments formula:
if (ChannelIds == null || !ChannelIds.Any()) { return "1"; // Return "1" if ChannelIds is null or empty}return string.Join(",", ChannelIds);Update — Channel Assignments formula:
var originalValues = GetCustomFieldValue(DestinationValue.CustomFields, "Channel Assignments");List<int> originalList = new List<int>();if (!string.IsNullOrEmpty(originalValues)){ originalList = IntListFromString(originalValues);}// Ensure ChannelIds is not null before using Unionif (ChannelIds == null){ ChannelIds = new List<int>();}IEnumerable<int> union = originalList.Union(ChannelIds);string outputValue = string.Join(",", union); // More efficient than manual concatenationreturn outputValue;Placeholder value — replace during implementation: the default channel 1 in the Add formula is a BigCommerce channel identifier. Confirm that 1 is the correct channel for your store, or adjust the formula, in a staging environment before relying on it in production.
Add BigCommerce Customer Address TO iPaaS.com (child) / Update BigCommerce Customer Address TO iPaaS.com (child)
iPaaS.com data type: Customer Address
These are child collections of the customer transfer. Each address is linked to the parent Customer and transferred as part of the customer; there is no independent sync. Neither collection has a mapping filter, so every address on a transferred customer is processed. The Add and Update field tables are identical.
Mapping Type | Source Field (BigCommerce) | Destination Field (iPaaS.com Customer Address) | Description |
Field |
| FirstName | Recommended. The address contact's first name. |
Field |
| LastName | Recommended. The address contact's last name. |
Field |
| Company | Recommended. The company name on the address where present. |
Field |
| Address1 | Recommended. The primary street line, for a complete, deliverable address. |
Field |
| Address2 | Optional. The secondary street line where present. |
Field |
| City | Recommended. The city. |
Field |
| Region | Recommended. The state or region. |
Field |
| Country | Recommended. The country. |
Field |
| PostalCode | Recommended. The postal or ZIP code. |
Duplicate address prevention. To suppress duplicate addresses when an address is transferred as part of a full customer request, add a Static mapping to a destination field named PreventDuplicate on the collection. When its value is Y, y, or true, iPaaS.com searches the Customer's existing addresses for an exact match on every mapped field (excluding custom fields); on an exact match, the address is not added and no external ID is assigned. Standalone address-only transfers do not honor PreventDuplicate.
Add BigCommerce Customer Address TO iPaaS.com (standalone) / Update BigCommerce Customer Address TO iPaaS.com (standalone)
iPaaS.com data type: Customer Address
These standalone collections capture or update a BigCommerce address on its own, linking it directly to an already-transferred iPaaS.com Customer without re-running the parent customer transfer. Neither collection has a mapping filter. The field mappings are the same as the child address collections, with one difference: the Add standalone collection resolves and sets the parent Customer link. The Update standalone collection does not remap the parent link — it matches the existing address by its external-ID record and preserves the Customer link.
Mapping Type | Source Field (BigCommerce) | Destination Field (iPaaS.com Customer Address) | Description |
Field |
| FirstName | Recommended. The address contact's first name. |
Field |
| LastName | Recommended. The address contact's last name. |
Field |
| Company | Recommended. The company name on the address where present. |
Field |
| Address1 | Recommended. The primary street line, for a complete, deliverable address. |
Field |
| Address2 | Optional. The secondary street line where present. |
Field |
| City | Recommended. The city. |
Field |
| Region | Recommended. The state or region. |
Field |
| Country | Recommended. The country. |
Field |
| PostalCode | Recommended. The postal or ZIP code. |
Dynamic Formula (Add only) |
| CustomerId | Required (Add). Resolves the linked iPaaS.com Customer and sets the parent link. The Customer must already have been transferred to iPaaS.com for the link to resolve. Not present on the Update collection, which preserves the existing link. |
Testing and Validation
Test Scenarios
Customer create. Create a new customer in BigCommerce and verify a Customer record appears in iPaaS.com with the mapped name, email, company, notes, and channel assignments, and that the BigCommerce customer ID is stored in CustomerNumber.
Customer update. Change a field on an existing BigCommerce customer and verify the change propagates to the matched iPaaS.com Customer, and that existing channel assignments are preserved.
Email matching. Transfer a customer whose email matches an existing record and confirm the existing record is updated rather than a duplicate created, per the configured collision-handling method.
Address (child). Create a BigCommerce customer with one or more addresses and verify each address is captured as a Customer Address linked to the parent Customer.
Standalone address. Manually sync an address by its BigCommerce customer address ID and confirm it links to an already-transferred iPaaS.com Customer; confirm that syncing an address whose Customer has not transferred does not link.
PreventDuplicate. With a PreventDuplicate static mapping set to
trueon a child address collection, transfer a customer whose address exactly matches an existing one and confirm no duplicate address is created.
Validation Checklist
Only one of the standard or B2B customer mappings applies to any given customer.
The default channel ID has been reviewed and replaced with a store-appropriate value before enabling automatic transfers.
Required fields are populated: email for customers.
The correct collision-handling method is selected for the Customer collections.
Additional Notes
B2B Edition. Customers, companies, and users belonging to BigCommerce B2B Edition are handled by a separate set of collections and are out of scope for this article. See the Related Documents footer.
Outbound direction. Writing iPaaS.com customers and customer categories out to BigCommerce is documented separately in the companion iPaaS.com to BigCommerce Customer Mapping Documentation.