This article describes the known limitations of the BigCommerce integration. These are inherent to the current design of the integration and to the capabilities of the BigCommerce API, and they apply to all subscribers.

Because the integration spans many record types, the limitations are organized by feature. Each feature section opens with a Related mapping documentation line linking that feature's mapping documentation so you can go straight from a limitation to the collection it concerns. One behavior — how updates are written back to BigCommerce — applies across every collection that writes to BigCommerce, so it is described first. A consolidated Placeholder Values to Replace Before Go-Live checklist appears at the end of this article: the single pre-launch list of example values each subscriber must replace.

Except where a specific date is stated, every limitation below describes the integration's behavior at the time this documentation was written.

This behavior concerns every collection that writes to BigCommerce (the FROM iPaaS.com collections — products, variants, inventory, categories, gift cards, shipments, B2B companies and users, and transactions).

Each update writes every field its collection maps, replacing any change made to those fields in BigCommerce. For the product record itself and for gift cards, a field the collection does not map is left as it is in BigCommerce: the product Update collection, for example, leaves Name and Description to BigCommerce after the product is created.

What this means for you: map the fields iPaaS.com should keep current, and leave unmapped the fields BigCommerce should own. For other collections, including a product's variants, options, and units, validate an update round trip in a staging environment before go-live to confirm that nothing you rely on is cleared, and map a field to its current value with a DestinationValue approach if it is. This behavior is accurate at the time this documentation was written.

Related mapping documentation: BigCommerce Order Mapping Documentation and BigCommerce Transaction (write-back) Mapping Documentation. The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

An order transfers to iPaaS.com only when it is in an eligible state: it is not Incomplete, Pending, or Manual Verification Required; it is not a refund; it is not a deposit-ticket or gift-card-ticket clone (the -D and -GC order-ID suffixes); and it is not a quote-originated order. Orders that do not meet these conditions are handled by their own collections (refunds, tickets, and B2B quotes) or are skipped until they reach an eligible status.

What this means for you: an order you expect to see in iPaaS.com may not have transferred because it is still in a pre-completion status or because it is a refund, ticket, or quote that another collection owns. Review each collection's filter against your business rules, and coordinate the filters so a given order state is claimed by exactly one collection — enabling overlapping collections without coordinated filters can create duplicate or conflicting records. This behavior is accurate at the time this documentation was written.

Orders paid with the Clover Payment method are not processed by the standard Update BigCommerce Order TO iPaaS.com collection.

What this means for you: if you take Clover payments and need those order updates in iPaaS.com, review this exclusion with your implementation partner or MiSP before relying on the standard order-update flow. The Clover Payment label used in the filter is an example value — see the placeholder checklist. This behavior is accurate at the time this documentation was written.

The order shipping-address collection captures one shipping address per order.

What this means for you: if your store ships a single order to multiple destinations, validate the behavior in a staging environment before relying on this collection in production, and discuss multi-destination handling with your implementation partner or MiSP. This behavior is accurate at the time this documentation was written.

BigCommerce holds a single staff note per order, so the staff-note collection maps one note record with a fixed sequence number; customer and staff notes are handled by separate collections. Notes captured from an order are readable by anyone with iPaaS.com access.

What this means for you: expect at most one staff note per order to carry across, and be aware of note visibility before mapping notes that contain sensitive content. This behavior is accurate at the time this documentation was written.

Automatic (non-coupon) promotions do not carry a coupon code, so the CouponCode field can be empty on discounts that originate from an automatic promotion rather than from a coupon.

What this means for you: treat an empty coupon code on an automatic-promotion discount as expected, not as missing data. This behavior is accurate at the time this documentation was written.

The transaction write-back collections (Transaction Add / Update FROM iPaaS.com, and their billing-address and line children) send iPaaS.com order data back to BigCommerce. As delivered, their mapping filter is pinned to an always-false condition, so they process no records until the filter is updated. In addition, importing or updating shipping addresses and shipping methods on BigCommerce is not supported by these collections; only the billing address is written.

What this means for you: if you want iPaaS.com to create or update BigCommerce orders, update the filter on the transaction write-back collections to select the records you intend to send, and plan around the fact that shipping addresses and methods are not written. Because these are BigCommerce writes, the Unmapped Field Overwrite Risk described above applies — map every field you want preserved. Validate the flow in a staging environment before relying on it in production. This behavior is accurate at the time this documentation was written.

Related mapping documentation: BigCommerce Order Payment Mapping Documentation, BigCommerce Refund Mapping Documentation, and BigCommerce Deposit Ticket and Gift Card Ticket Mapping Documentation. The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

The data BigCommerce returns differs by payment type, so order, refund, and ticket payments are split across gateway-specific child collections — for orders and tickets: Credit Card / Apple Pay, PayPal, Gift Card, Check, and Test Payment Gateway; for refunds: Credit Card, PayPal, Check, and Test Payment Gateway. If a transaction uses a payment type not covered by the supplied collections, an additional payment sub-collection may be needed.

What this means for you: if you accept a payment type that is not one of the ones listed above, review it with your implementation partner or MiSP to confirm whether a separate payment sub-collection is required before you rely on that payment data in production. This behavior is accurate at the time this documentation was written.

Payments taken through the test payment gateway are recorded with a payment method of Other rather than a specific payment brand.

What this means for you: if you need a more specific method recorded for test-gateway payments, customize the mapping and validate it in a staging environment. This is a design choice for the shipped mapping, not a defect, and is accurate at the time this documentation was written.

When an order includes gift-card sales, the gift-card portion is recorded on a separate gift-card ticket and is deducted from the order's other payment amounts and from deposit-ticket subtotals and totals.

What this means for you: expect the gift-card portion of a mixed order to appear on the gift-card ticket rather than on the order's other payment records. This keeps the ticket totals consistent with how your accounting system consumes them. This behavior is accurate at the time this documentation was written.

Deposit tickets and gift-card tickets are cloned order records (the -D and -GC order-ID suffixes) designed to be sent onward to an ERP or accounting system. If your destination system does not use tickets, or your business does not sell gift cards in BigCommerce, these collections and their children can be removed.

What this means for you: keep the ticket collections only if a downstream accounting system consumes them; otherwise remove them to avoid processing records you do not need. Several ticket mappings should be reviewed to confirm they are configured for your B2B and/or B2C order flows before you rely on them in production. This behavior is accurate at the time this documentation was written.

The gift-card-ticket Credit Card, Check, and Test Payment Gateway payment collections create the payment record but do not update an existing payment.

What this means for you: treat these payment records as created once with the ticket; later changes to the payment are not re-written by these collections. This behavior is accurate at the time this documentation was written.

Related mapping documentation: BigCommerce Product Mapping Documentation, BigCommerce Product Variant Mapping Documentation, and BigCommerce Inventory Mapping Documentation. The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

Product and variant kits are not supported by the BigCommerce integration.

What this means for you: if your catalog uses kits, discuss how to represent them with your implementation partner or MiSP; they will not transfer as kits through the product and variant collections. This behavior is accurate at the time this documentation was written.

When a variant-type product's option values are edited directly in BigCommerce, BigCommerce automatically generates variant SKUs for any missing variant-option combinations. Those auto-generated SKUs conflict with the variants iPaaS.com creates, and they are not compatible with the order-line SKU mappings.

What this means for you: edit a product's option values in BigCommerce only after all of that product's variants have been created by iPaaS.com. Editing option values before every variant exists lets BigCommerce fill in the gaps with its own SKUs, and the resulting duplicate-SKU conflicts will prevent future updates to the product. To keep iPaaS.com from overwriting option-value data you maintain in BigCommerce (such as colors or pattern URLs), use the SpecialVariantOptionExclusions custom field described in the product mapping documentation. This behavior is accurate at the time this documentation was written.

BigCommerce returns a product option's values in pages of 50. A defect in the BigCommerce API currently prevents retrieving any page beyond the first — requesting a later page returns the first page again, and the page-size parameter that would return all values in one request is rejected. As a result, when an option has more than 50 values, the integration can reliably read only the first 50.

What this means for you: keep the number of values on any single product option at 50 or fewer. An option with more than 50 values — for example a very large size or color list — cannot be fully retrieved from BigCommerce while this defect persists, which can leave the later values unsynchronized and updates incomplete. If you need more than 50 values on one option, discuss the design with your implementation partner or MiSP. This reflects a BigCommerce API defect that is open at the time this documentation was written.

When a product's UnitHandling is V and the product has two or more units of measure, the integration represents the units in BigCommerce as a Unit option, with one value per unit, and one variant per unit — for a product with variants, one per variant and unit. The integration adds units and keeps their prices and stock up to date, but it never removes a unit's variants, its option value, or the Unit option from BigCommerce. Changes to a product's units in iPaaS.com are therefore not reconciled in BigCommerce:

There is no automatic repair for a product in this state at the time this documentation was written.

What this means for you: decide each product's units of measure before its first transfer to BigCommerce, and treat them as fixed. If a product's units must change — a renamed unit, a removed unit, or a return to a single unit — plan the change with your implementation partner or MiSP, and validate it on a test product in a staging environment before applying it to a live product. This behavior is accurate at the time this documentation was written.

The integration reads and writes stock levels using BigCommerce's standard product- and variant-level inventory. It does not use BigCommerce's multi-location inventory (Locations) feature; stock is maintained at the store level.

What this means for you: if your BigCommerce store uses multi-location inventory, the integration still reads and writes a single store-level stock figure per product or variant rather than per-location quantities. Plan inventory around the store-level total, and if you need per-location inventory managed through the integration, discuss the approach with your implementation partner or MiSP. This behavior is accurate at the time this documentation was written.

The integration writes BigCommerce inventory from one iPaaS.com location. The inventory collections filter on a location name, and inventory records for any other location are skipped.

What this means for you: choose the single iPaaS.com location that holds the inventory you send to BigCommerce and set it in the inventory collections' filters (the shipped example name is MAIN — see the placeholder checklist). If you need inventory from more than one location, contact your implementation partner or MiSP. This behavior is accurate at the time this documentation was written.

BigCommerce rejects inventory levels below zero. The default inventory mappings guard against this — a negative source quantity is sent as 0, using the Larger(QtyAvailable, 0) function in the mapping.

What this means for you: if your source stock can go below zero, keep the guard in place (or add one) so the integration never sends a negative number, which BigCommerce would reject. This behavior is accurate at the time this documentation was written.

For a newly added product, inventory external IDs are not linked until a full product update is performed.

What this means for you: if you rely on the inventory external-ID link, expect it to be established after the first full product update rather than at initial creation. This behavior is accurate at the time this documentation was written.

The product and variant channel-assignment mappings ship as example logic that assigns records to channel 1 (your first store). If no channel is specified in a mapping, BigCommerce defaults the record to channel 1.

What this means for you: replace the example channel logic with your own channel-selection rules before relying on channel assignments. Stores set up with BigCommerce Multi-Store Fulfillment require the correct channel IDs — contact your implementation partner or MiSP for guidance. This behavior is accurate at the time this documentation was written.

The Add/Update BigCommerce Product TO iPaaS.com collection does not map Description. Because the collection sends no description, each product update from the store leaves the iPaaS.com product's description empty. Categories and inventory are kept. The collection ships with a filter that blocks every record, so this applies only once you change that filter.

What this means for you: before enabling product transfers TO iPaaS.com, add a Description mapping to that collection, or keep it disabled if iPaaS.com is your source for product descriptions. This behavior is accurate at the time this documentation was written.

The Delete BigCommerce Product TO iPaaS.com and Delete BigCommerce Product Variant FROM iPaaS.com collections let deletions in one system remove the record in the other. Delete collections carry no field mappings by design.

What this means for you: decide which system is your source of truth for products and variants, and enable a delete collection (and its corresponding webhook) only when you want deletions to propagate. Do not add field mappings to a delete collection. This behavior is accurate at the time this documentation was written.

Related mapping documentation: BigCommerce Product Category Mapping Documentation. The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

The BigCommerce default mappings in iPaaS.com are built around a single category tree.

What this means for you: if you want to build out multiple category trees in BigCommerce, contact your implementation partner or MiSP for the additional configuration. This behavior is accurate at the time this documentation was written.

The integration does not delete BigCommerce categories in response to an iPaaS.com category delete. Removing a category in iPaaS.com does not remove it in BigCommerce; category cleanup in BigCommerce is a manual store operation.

What this means for you: plan to remove unwanted BigCommerce categories manually in the store — deleting them in iPaaS.com will not do it. This is a deliberate safeguard against unintended catalog changes. This behavior is accurate at the time this documentation was written.

Subscribing to the iPaaS.com product-category-updated event for the category-assignment flow can create transfers that run but usually perform no action, because the product is already assigned to the same category.

What this means for you: subscribe selectively to category-update events for the assignment flow to avoid redundant transfers. This behavior is accurate at the time this documentation was written.

Related mapping documentation: BigCommerce Customer Mapping Documentation (iPaaS.com to BigCommerce, and BigCommerce to iPaaS.com) and the B2B Company and Customer Mapping Documentation articles. The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

Customers and B2B Edition records (companies, users, quotes, and invoices) can be brought into iPaaS.com by polling. The first time a poll runs there is no saved starting point, so it picks up every existing record of that type in the store, not only recent changes, and passes each through your collections and their filters. There is no setting that limits how far back the first poll looks.

What this means for you: expect a large first transfer. Finish your mappings and filters, and remove test records from the store, before you enable polling. This behavior is accurate at the time this documentation was written.

The default template does not delete customers in either direction. A customer deleted in one system stays in the other unless you add a customer collection with the Delete sync type in the direction you need. For B2B Edition customers, deleting the iPaaS.com customer through such a collection deletes only the B2B Edition user: the BigCommerce store customer stays, and with the store customer webhook enabled it returns to iPaaS.com as a new customer.

What this means for you: decide which system is your source of truth for customers before adding a delete collection, and for B2B Edition customers also remove the store customer in BigCommerce. This behavior is accurate at the time this documentation was written.

Related mapping documentation: the B2B Company and Customer Mapping Documentation articles, BigCommerce B2B Quote Mapping Documentation, and the two B2B Invoice Mapping Documentation articles (iPaaS.com to BigCommerce, and BigCommerce to iPaaS.com). The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

The B2B Company, B2B Customer, and their address and relationship collections apply only to stores using BigCommerce B2B Edition.

What this means for you: if you are not using BigCommerce B2B Edition, delete the B2B collections — they have nothing to process. This behavior is accurate at the time this documentation was written.

A B2B relationship's Type is derived from the BigCommerce B2B role, and only the four BigCommerce B2B roles are represented: Super Admin, Admin, Senior Buyer, and Junior Buyer.

What this means for you: expect B2B relationships to resolve to one of those four roles. If your workflow needs a role concept BigCommerce does not define, discuss it with your implementation partner or MiSP. This behavior is accurate at the time this documentation was written.

When a company is sent with a parent company whose B2B Edition status is still pending, the child company is created and linked, but B2B Edition refuses to attach it to a pending parent. The transfer fails, and the child company has no parent until the parent is approved and the child is sent again.

What this means for you: approve the parent company in B2B Edition before sending its child companies. If a child was sent first, send it again after the parent is approved. This behavior is accurate at the time this documentation was written.

Creating and updating BigCommerce B2B quotes is not implemented at the time this documentation was written. The B2B Quote collections (header, line, addresses, notes, and legal terms) are provided for completeness, but no quote is written to BigCommerce.

What this means for you: do not rely on the B2B Quote collections to create or update quotes in BigCommerce yet. If B2B quote write-back is important to your workflow, submit a feature request through your iPaaS.com partner channel, and validate quote behavior in a staging environment before relying on it in production. This behavior is accurate at the time this documentation was written.

The supported B2B invoice flow is a round trip that starts in iPaaS.com: an Invoice Transaction (typically created by your ERP once an order ships) creates the invoice in B2B Edition, and later changes to that invoice — payments, open balance, and status — come back onto the same Invoice Transaction. Invoices created directly in B2B Edition are not imported: they have no Invoice Transaction in iPaaS.com to update, and the order collections skip any record that carries an invoice number. B2B Edition also generates only one invoice per order.

What this means for you: create B2B invoices from iPaaS.com through Add BigCommerce B2B Invoice FROM iPaaS.com rather than in B2B Edition, and adapt that collection's order-resolution example before enabling it (see the placeholder checklist below). This behavior is accurate at the time this documentation was written.

Related mapping documentation: BigCommerce Gift Card Mapping Documentation. The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

The gift-card activity collection records the initial issuance of a gift card. Later balance movements — redemptions and adjustments — are not recorded by this collection.

What this means for you: use the activity collection for issuance tracking; if you need ongoing balance history, discuss the approach with your implementation partner or MiSP. This behavior is accurate at the time this documentation was written.

When an order contains gift-certificate line items, the corresponding gift cards are created automatically during order preprocessing. This can be turned off with the Disable Gift Card Auto-Creation During Order To iPaaS Preprocessing subscription setting.

What this means for you: if you do not want gift cards created automatically as part of order transfers, enable that subscription setting. This behavior is accurate at the time this documentation was written.

Removing a gift card in BigCommerce can propagate the delete to the linked iPaaS.com record.

What this means for you: confirm the delete behavior against your business rules in a staging environment before relying on it in production. This behavior is accurate at the time this documentation was written.

Related mapping documentation: BigCommerce Shipment Mapping Documentation. The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

The Shipment FROM iPaaS.com collection writes shipment data to orders that already exist in BigCommerce (it does not create orders). As delivered, its mapping filter is pinned to an always-false condition, so it processes no records until the filter is updated.

What this means for you: if you want iPaaS.com shipments written to BigCommerce, review and update the filter on the shipment collection to select the records you intend to send. Because this is a BigCommerce write, the Unmapped Field Overwrite Risk applies — map every field you want preserved. This behavior is accurate at the time this documentation was written.

Tracking entries that share a tracking number become one BigCommerce shipment, and the shipped items come from each entry's Shipment Line No value. Once that shipment exists in BigCommerce, its items cannot be changed: BigCommerce does not allow a shipment's items to be edited, so later updates change only details such as the tracking number. Moving an item that has already shipped to a different tracking number fails, because BigCommerce refuses a second shipment for units that have already shipped. The transfer reports the error and is retried.

What this means for you: settle which items ship under which tracking number in your source system before the tracking is sent to BigCommerce. If a shipment needs different items afterwards, correct it in BigCommerce (delete the shipment and create the right ones) rather than re-sending the tracking from iPaaS.com. This behavior is accurate at the time this documentation was written.

The integration's templates ship with example / environment-specific values that each subscriber must replace before enabling the affected collection. This is the consolidated pre-launch checklist; the full context for each item is in the feature sections above and in the linked mapping documentation.

Several of these values are test scaffolding carried over from the integration's build environment. They will not work in your store and must be replaced — the guest email domains and the customer-group filter value in particular.

For the field-level detail behind any limitation or checklist item, follow the Related mapping documentation links in each feature section above and the corresponding collection descriptions in the iPaaS.com mapping configuration.