BigCommerce products can be built and kept up to date from iPaaS.com. A single product transfer writes the product and all of its related data to BigCommerce in one pass — variants, the options and option values that define them, alternate units of measure, inventory levels, and category assignments — and companion collections handle category tree building, lightweight inventory-only updates, and deletions. Almost every collection in this document writes from iPaaS.com to BigCommerce; the one exception is the product-delete flow, which lets a BigCommerce deletion remove the matching product from iPaaS.com. Kits are not supported by the BigCommerce integration at this time.

For the parent product collections, enter the iPaaS.com product ID — the numeric identifier iPaaS.com assigns to the product record — on the Manual Sync page. Example: 288. Transferring a product this way also transfers its variants, options, option values, and units, because those child collections have no independent Manual Sync entry point.

The standalone collections take their own iPaaS.com record ID:

After a successful product transfer, iPaaS.com records the BigCommerce product ID as the external ID on a dedicated external-ID record. That record is the primary match that routes a later change of the same product to an update rather than creating a duplicate. Products and variants are also matched to BigCommerce on SKU: a SKU that already exists in BigCommerce links to that product or variant instead of creating a new one. Related records (categories, options, option values, units) are matched on external ID. Inventory external IDs are not linked until a full product update has been performed.

Two delete flows are included in the default template, and each moves in a different direction:

Delete collections carry no field mappings by design — a delete is driven by the source record's identity and the collection's external-ID link, not by mapped fields. Both delete flows require an existing external-ID link between the two systems; a record that was never transferred has nothing to remove on the other side.

Category deletes are intentionally suppressed: the integration does not delete a BigCommerce category when its iPaaS.com category is deleted. Category cleanup in BigCommerce remains a manual store operation.

Be deliberate about your system of record. The Delete BigCommerce Product TO iPaaS.com flow lets BigCommerce deletions remove products from iPaaS.com. If iPaaS.com is your source of truth for products, do not enable that collection or the BigCommerce product-deleted webhook. Likewise, enable the variant-delete flow only if iPaaS.com should be able to remove variants from BigCommerce.

The product collections support BigCommerce custom fields. Custom fields are configured in the subscription under Subscription Management → Subscriptions → BigCommerce → Custom Fields, with the module set to BC Product. Once configured, a custom field can be read from and written to BigCommerce as part of the product transfer.

The integration uses custom fields to drive several product behaviors:

All Product collections in this document are Enabled by default. Their trigger events depend on direction:

Several collections carry a mapping filter that restricts which records they process; those are documented per collection in the Mappings section.

Several collections operate on the same BigCommerce product data. Review each collection's filter and Add/Update settings before enabling, and decide which collection is the source of truth for each product state:

Every FROM iPaaS.com collection in this document writes the full record to BigCommerce on each transfer. Fields you leave unmapped can be overwritten — reset to empty or default — each time the record transfers. To protect a field you do not source from iPaaS.com, either map it explicitly or use a DestinationValue approach so the current BigCommerce value is written back unchanged (the category Update collection does this for the storefront URL path). This behavior is accurate at the time this documentation was written.

The parent product collections drive a chain of child collections that transfer as part of the product create or update:

The remaining product-family collections are standalone — they are triggered by their own record events rather than as part of a product transfer: Product Category, Product Category Update, Product Category Assignment (add/update and delete), Product Inventory, Product Variant Inventory, the two realtime inventory collections, Product Variant Delete, and Product Delete.

Enable the relevant record-change events under Outbound Data Flows in the subscription configuration so transfers run automatically:

For the inbound Delete BigCommerce Product TO iPaaS.com flow, configure the BigCommerce product-deleted webhook and enable the corresponding event under Inbound Data Flows.

If you use price lists with price rules, configure the per-customer-group Pricing_{BigCommerce Customer Group ID} custom field and the PriceList_Currency value before enabling the price-list-related mappings.

See the BigCommerce Installation Instructions for the full webhook and data-flow setup steps.

When a product is transferred FROM iPaaS.com, the integration writes the product and its related records to BigCommerce in sequence:

For the inbound delete flow, a BigCommerce product-deleted webhook (or a Manual Sync of the deleted product) locates the linked iPaaS.com product by its external ID and removes it.

Each collection below lists its iPaaS.com data type in plain terms, a Mapping Filter block where the live collection carries a filter, and its field mapping table. Near-identical Add and Update collections are combined into one subsection with any deltas noted. In the tables, the Source Field (iPaaS.com) column shows the actual field name, static value, or dynamic-formula body from the live mapping. Formula bodies that update inventory, resolve brands, or expand custom fields are shown inline; the longer ones are also explained in the Custom Fields / Product Behaviors (Reference) section.

iPaaS.com data type: Product

This is the parent collection. The Add collection creates a new BigCommerce product; the Update collection changes an existing one. Neither collection carries a mapping filter by default — all product records are processed. (An optional price-list gating filter is available; see Additional Notes.) The tables below cover both; Add-only and Update-only rows are marked.

InventoryLevel formula (Add / Update):

Placeholder value — replace during implementation: the location name MAIN is an example iPaaS.com location name. Replace it with the name of the location that holds the inventory you send to BigCommerce.

InventoryTracking formula (Add / Update):

ChannelAssignments scaffold (Add / Update):

The scaffold always assigns channel 1. Replace the placeholder logic with the channel-assignment rules your store requires, especially under Multi-Store Fulfillment.

Pimcore Product Attributes formula (Add / Update):

This reads the raw JSON in the Pimcore Product Attributes custom field and parses it into key/value pairs that are written as individual BigCommerce custom fields.

iPaaS.com data type: Product Variant

Child of the Product collection. Creates or updates a variant and links it to its parent product. Both the Add and Update collections carry the price-list gating filter below.

Mapping Filter

Filter Description. The filter gates each variant on a BigCommerce customer group being ready for price lists. It resolves the customer group to an iPaaS.com Customer Category; if that link does not exist, the transfer stops with "This customer group (id: 31) does not exist or interlinked with any iPaaS Customer Category". If the link exists, the filter then checks whether the customer group appears in any BigCommerce price list; if it does not, the transfer stops with "This customer group (id: 31) does not exist in any price list of Bigcommerce". Only when both checks pass does the variant transfer. Subscribers who do not gate variant creation on price-list membership can remove the filter.

Placeholder value — replace during implementation: the filter hardcodes customerGroupId = 31. This is a development/example customer-group ID. Replace 31 with the BigCommerce customer-group ID your configuration uses before enabling the collection — as written, the filter evaluates only customer group 31 and will reject or misgate every real variant that belongs to a different group.

iPaaS.com data type: Product Variant Option

Child of the Variant collection. Creates the option/value pairs (for example Size and Color) that define a variant. No mapping filter. Add and Update map identical fields.

iPaaS.com data type: Product Option

Child of the Product collection. Creates a shared product option (for example Color or Size) that variants draw values from. No mapping filter. Add and Update map identical fields.

Lookup Translation Tables

The BC Product Option Type From iPaaS translation is customized per subscriber. Map each iPaaS.com option type to the BigCommerce control type your storefront uses. iPaaS.com options are designed around color as a default; additional types can be added by your implementation partner.

iPaaS.com data type: Product Option Value

Child of the Product Option collection. Creates the allowed values for an option (for example the individual color or size choices). No mapping filter. Add and Update map identical fields.

Lookup Translation Tables

A representative sample is shown (24 pairs configured). The BC Product Option Value Color Swatch From iPaaS translation is customized per subscriber. Map each source color to the swatch color you want displayed.

iPaaS.com data type: Product Unit

Child of the Product collection. Writes an iPaaS.com alternate unit of measure to BigCommerce. No mapping filter. Add and Update map identical fields.

iPaaS.com data type: Product Inventory

Seeds the inventory level on a newly added BigCommerce product. Variant inventory is handled by the companion Variant Inventory collection.

Mapping Filter

Filter Description. The record is processed only when both conditions hold: the record's LocationId matches the configured location (resolved from the name MAIN), and the product has already been transferred to BigCommerce (an external product ID resolves for the ParentId). Any record for a different location, or for a product not yet in BigCommerce, is skipped.

Placeholder value — replace during implementation: the location name MAIN is an example. Replace it with the name of your iPaaS.com location that holds the inventory you send to BigCommerce.

iPaaS.com data type: Product Variant Inventory

Seeds the inventory level on a newly added BigCommerce variant.

Mapping Filter

Filter Description. Processes a variant inventory record only when the record's location matches the configured location and the variant has already been transferred (a variant external ID resolves for the ParentId). Records for other locations or for variants not yet in BigCommerce are skipped.

Placeholder value — replace during implementation: replace the location name MAIN with your iPaaS.com inventory location name.

The variant's external-ID link encodes both the parent product ID and the variant ID, separated by a |. The Id mapping takes the segment after the |; the ProductId mapping takes the segment before it:

iPaaS.com data type: Product Inventory

A lightweight collection that updates a product's inventory level as stock changes, without rewriting the whole product.

Mapping Filter

Filter Description. Processes an inventory record only when its LocationId matches the configured location (resolved from the name MAIN). Records for any other location are skipped.

Placeholder value — replace during implementation: replace the location name MAIN in the filter with your iPaaS.com inventory location name.

Placeholder: replace MAIN in the formula's non-kit branch with your location name.

iPaaS.com data type: Product Variant Inventory

A lightweight collection that updates a variant's inventory level as stock changes.

Mapping Filter

Filter Description. Processes a variant inventory record only when its LocationId matches the configured location (resolved from MAIN). Records for other locations are skipped.

Placeholder value — replace during implementation: replace the location name MAIN with your iPaaS.com inventory location name.

iPaaS.com data type: Product Category

Builds and maintains the BigCommerce category tree. Both Add and Update carry the parent-ordering filter below. The Add collection sets TreeId and generates the storefront UrlPath; the Update collection omits TreeId and preserves the existing BigCommerce URL path. Category creation matches on the category Name; when a name already exists, the configured collision-handling method (remap-and-link, update-and-link, update-and-no-link, or error) is applied.

Mapping Filter

Filter Description. The filter enforces parent-before-child ordering. When the category has a ParentId but that parent has not yet been transferred to BigCommerce (no external ID resolves), the transfer stops with "Parent category must be transferred first". Categories with no parent (top-level categories) always pass. No value in this filter is environment-specific, so no placeholder substitution is required.

UrlPath formula (Add only):

iPaaS.com data type: Product Category Assignment

Assigns a product to a category. It does not create the product or the category — both must already exist in BigCommerce.

Mapping Filter

Filter Description. Processes an assignment only when its category has already been transferred to BigCommerce — a BigCommerce category ID (value) resolves for the CategoryId. Assignments whose category does not yet exist in BigCommerce are skipped. No value in this filter is environment-specific, so no placeholder substitution is required.

iPaaS.com data type: Product Category Assignment

Removes the link between a product and a category. Delete collections have no field mappings by design.

Mapping Filter

Filter Description. Processes a removal only when the assignment's category has already been transferred to BigCommerce (a category ID value resolves for the CategoryId). This restricts deletes to assignments for categories that exist in BigCommerce and skips the rest. No value in this filter is environment-specific, so no placeholder substitution is required.

This collection has no field mapping table — the removal is driven by the source assignment's identity and the filter above.

iPaaS.com data type: Product Variant

Deletes a variant in BigCommerce when it is removed in iPaaS.com; the parent product remains. No mapping filter, and no field mappings by design — the delete is driven by the variant's external-ID link. The variant must already have a BigCommerce external ID for the delete to locate and remove it.

iPaaS.com data type: Product

Removes a product in iPaaS.com when BigCommerce reports the product deleted. This is the only inbound collection in this document. No mapping filter, and no field mappings by design — the delete uses the existing external-ID link between the BigCommerce product and the iPaaS.com product. The product must already be linked for the delete to find and remove it.

Several product behaviors are driven by custom fields and by helper functions you place in dynamic-formula mappings. These are the formulas subscribers and implementation partners edit directly, so short function names are shown inline. Add each behavior as a single dynamic-formula mapping on the parent Product Add and Product Update collections unless noted otherwise.

Product Modifiers let shoppers enter values that travel with a line item when the product is sold — presented in addition to variant options such as Size and Color. To use them: add the modifier in BigCommerce, add a matching BigCommerce custom field in the iPaaS.com subscription (module BC Product; the custom-field name becomes the modifier's display name in BigCommerce), then map it on the parent Product collections with one of the functions below. The destination is the custom field you created; the source is a dynamic formula.

Each function creates a different modifier control type. The required boolean is always the first argument.

BigCommerce requires a default for drop-down, rectangle, radio-button, and swatch modifiers. If you do not set one, BigCommerce makes the first entry the default. Example usages:

Price Adjusters. ToDropDownModifier has an overload that accepts a list of prices to apply as price adjusters to the option values: ToDropDownModifier(required, defaultValue, optionValues, priceModifier). Supply one price to apply it to every value, or one price per value in order.

RemoveModifier(). When a mapping uses this function, the modifier named in the mapping's field is checked for existence in BigCommerce and removed if present. Use it to retire a modifier you previously added.

To accept modifier values on the product's line items, the modifiers must also be added to the Transaction Line mappings. See the BigCommerce Transaction (Order) documentation for that step.

iPaaS.com can send an external, publicly accessible image URL into BigCommerce using ProductImageListFromFilenames. Map it as a dynamic formula on the parent Product collections.

Null-return requirement. A mapping using this function must return null when no image is provided. If it returns an empty value instead, the transfer fails because BigCommerce requires the image_url field to be supplied. Guard the formula, for example:

To set a storefront redirect for a product, map both RedirectUrl and RedirectUrlSite on the product — both are required for a redirect to apply. The site is identified by its BigCommerce site ID, which you resolve with one of:

Related products can be sent by mapping a dynamic formula to the RelatedProducts field: ConvertRelatedProductsToBigCommerceIdsAsync(relatedProducts, typeFilter). The typeFilter is optional — omit it to include all related products that have BigCommerce external IDs, or pass one of Replacement, Similar Item, or Related Product to include only that type. The related products must already exist in BigCommerce for their IDs to resolve.

When subscribers update variant option ValueData fields (such as colors or pattern URLs) directly in BigCommerce and do not want iPaaS.com to overwrite them, create a BigCommerce custom field in iPaaS.com named SpecialVariantOptionExclusions (case sensitive) and map it on the product Add/Update. It marks the named option-value data to be excluded from the full-replace write.

BigCommerce inventory is tracked from a single iPaaS.com location. Every inventory mapping and filter references the location name MAIN as a placeholder — replace it with the name of the iPaaS.com location that holds the inventory you send to BigCommerce (Settings → Locations). BigCommerce rejects negative inventory; the default mappings floor the value at zero, and where a source value could go negative you can wrap it with Larger(QtyAvailable, 0) so it never falls below zero.