Summary

An iPaaS.com Transaction can be transferred to HubSpot as a HubSpot order, carrying the order totals, the customer or company reference, the billing and shipping information, and the line items. Order creation and order updates are handled by two separate collections, and which one runs is decided by whether the iPaaS.com Transaction is already linked to a HubSpot order. The transaction's lines travel with it as HubSpot line items through the child collections. This direction is outbound only: HubSpot orders are not transferred back into iPaaS.com.

ID Format

Manual Sync ID Format

Enter the iPaaS.com Transaction id on the iPaaS.com Manual Sync page to transfer that transaction to HubSpot. Line items have no manual sync id of their own; they are transferred only as part of their parent transaction, using the iPaaS.com Transaction id.

External ID Format

The HubSpot order id assigned when the order is created is recorded as the external-id link on the iPaaS.com Transaction. That link is what routes every later change to the Update HubSpot Order FROM iPaaS.com collection instead of creating a second order, and it identifies the HubSpot order to update. Each line item is linked in the same way: the HubSpot line item id assigned at creation is recorded as the external-id link on the iPaaS.com transaction line.

The link is maintained by the integration itself rather than by a mapping, so neither order collection carries a mapping that resolves the HubSpot order id.

Deleted Record Support

Outbound delete is not supported. Deleting a transaction in iPaaS.com does not delete or deactivate the order in HubSpot, and removing a line from an iPaaS.com Transaction does not remove the line item from the HubSpot order. Delete mappings are not included in the default templates, and deletions do not propagate in any form. Removing an order or a line item in HubSpot is a manual action performed under a supervised process.

Custom Field Support

Custom fields are supported for all four collections. A custom field lets subscribers or their MiSP populate a HubSpot order or line item property that is not covered by the standard mappings.

The HubSpot property must be created manually before the mapping will work. In HubSpot, go to Settings, then Data Management, then Properties, and create the property against the Order object type — or the Line Item object type for a line item property — in the group of your choice. On the Field type tab, Single-line text is the usual choice. The iPaaS.com custom field name must match the HubSpot property's label; the integration looks the label up against the live property list and writes to the matching HubSpot property.

To use a custom field, add a Transaction module custom field — or a Transaction Line module custom field for a line item — on the iPaaS.com custom fields page for the HubSpot subscription, then create a mapping to it in the appropriate collection with the source data of your choice.

Provide source data that suits the HubSpot property's field type, otherwise HubSpot may reject the value or store something unexpected:

Text: values can typically be provided as-is.
Number: only numeric values are accepted.
Date: source data must be provided in Epoch time format.
Boolean or Checkbox: set with the value true or the value false, where true means Yes.
Multi-select: use a semicolon to separate multiple values in the source data. A source value of first;second sets two options.

A custom field that should be maintained on every change must be mapped in the Update collection as well as in the Add collection. A custom field mapped only in the Add collection is set once, when the record is first created.

Two custom fields are read by the default template mappings and are worth creating on the iPaaS.com Transaction module if a HubSpot owner should be set on the order: HubSpot Owner Id and HubSpot Owner Email. At least one of them must carry a value for an owner to be set. Setting the owner id performs better than searching by email address. Both of these mappings target a standard HubSpot order property rather than a custom one.

Mapping Collection Status

Status: Enabled. All four collections are enabled, in the FROM iPaaS.com direction only.

Trigger Events: These are FROM iPaaS.com collections, so they are driven by iPaaS.com outbound triggers, which subscribers or their MiSP enable under Outbound Data Flows in the subscription configuration. Subscribe to the iPaaS.com Transaction create and update events that should dispatch a transfer. No automatic transfers occur until those subscriptions are enabled. Manual Sync is available on the parent collections regardless. Whether a given transfer runs as an Add or an Update is decided by the external-id link, not by which event was raised. The line item collections have no trigger of their own: they run whenever their parent transaction transfers, by either method.

Duplicate or Conflicting Mappings

No duplicate check is performed when a transaction is transferred to HubSpot. An iPaaS.com Transaction that is not yet linked to a HubSpot order produces a new HubSpot order, even when an order representing the same purchase already exists in HubSpot.

HubSpot does not deduplicate orders created through an API, including orders created by an integration. Where the same orders exist on both platforms, this can produce two HubSpot orders for one purchase. Subscribers or their MiSP should link or reconcile pre-existing HubSpot orders before enabling outbound transaction transfers at scale.

No duplicate is possible from the Update collection. It only ever updates the one HubSpot order already linked to the iPaaS.com Transaction, so a repeated transfer of the same transaction re-applies the mapped fields to that same order rather than creating another one. The same is true of the line item collections: each line on the iPaaS.com Transaction produces one HubSpot line item on the order, and a HubSpot line item belongs to a single parent record, so the line items written here belong to that order alone.

A HubSpot order property that is not mapped is left as it is when the order is updated, so values maintained by hand in HubSpot on unmapped properties are preserved. Where a property is mapped, the iPaaS.com value is authoritative and replaces what is in HubSpot on every transfer.

There is no opposite-direction transaction collection, so nothing contends with these collections from the HubSpot side. Review the Add and Update settings across all four collections, and decide which fields should be create-only, before enabling outbound transaction transfers.

Supported Child Collections

Add HubSpot Order Line Item FROM iPaaS.com: creates the order's HubSpot line items from the iPaaS.com transaction lines. It runs under Add HubSpot Order FROM iPaaS.com, as part of that transaction's transfer, once the HubSpot order exists.
Update HubSpot Order Line Item FROM iPaaS.com: maintains the line items on an order that is already linked. It runs under Update HubSpot Order FROM iPaaS.com, as part of that transaction's transfer.

Which line item collection runs follows entirely from which parent collection runs, so the two never overlap. Neither child collection has children of its own.

System Caveats

HubSpot Caveats

The order currency is stamped once: the currency is set only when the order is created, and is not re-sent by the Update collection. A currency corrected in HubSpot after creation is left alone by later transfers. See the Add HubSpot Order FROM iPaaS.com mappings below.
The owner is opt-in: no HubSpot owner is set unless one of the two owner custom fields on the iPaaS.com Transaction carries a value. When both are empty on an update, the owner already on the HubSpot order is left unchanged rather than being cleared. The mapping may be changed to a static owner id if the same owner should be set on every order.
Owner email lookup: resolving an owner by email address costs an additional lookup against HubSpot. Setting the owner id directly performs better.
Line items cannot be added to an order by hand in HubSpot: they arrive with the order through the child collections.
A line item without a product reference is still written: it carries the name, SKU, and description as text but is not linked to a HubSpot product record.
Product lookup by SKU costs a call: each line resolves its product against HubSpot, so orders with many lines take longer to transfer.
Re-linking on update: the contact or company reference and each line's product reference are recalculated on every transfer, so a customer, company, or product transferred to HubSpot after the order was first created is picked up on the next update.
Rate limiting: at the time this documentation was written, the integration does not wait and retry when HubSpot throttles it. A throttled transfer fails and must be re-run. The failure is reported under Dashboard, Integration Monitoring, Error Logs.

iPaaS.com Caveats

One billing address and one shipping address are sent: the address mappings read the iPaaS.com Transaction's primary billing address and primary shipping address, because the HubSpot order holds a single address of each kind. A transaction with no address flagged as primary billing sends no billing address, and the same applies to shipping. Change these mappings if a different address should populate the HubSpot order.
Every transaction has a customer reference: iPaaS.com requires that each transaction is tied to a customer, a company, or an email address, so the linking mapping always has something to work from. What it resolves to still depends on whether that customer or company has been transferred to HubSpot.
The transaction number and status always carry a value: iPaaS.com requires both on every transaction, so the mappings that read them are reliable for every record.
Lines carry a status and a type: iPaaS.com requires both on every transaction line, and neither is mapped to HubSpot. A line's type is either Product or Giftcard.
A SKU refers to a product or a variant: iPaaS.com requires that a line's SKU resolves to an existing product or variant when the line's type is Product. Where the SKU belongs to a variant, the product reference falls back to the variant's parent product.
The prerequisite setting is exact: the Transfer Products as a Prerequisite for Transactions subscription setting is recognised only when it reads exactly true. Values such as 1, yes, or on silently disable product prerequisites rather than reporting a configuration error.
The shipped line item formulas suppress a zero: the quantity, price, amount, discount, and tax mappings ship with formulas that send a value only when it is greater than zero. This is the formula's behaviour and can be changed. See Additional Notes.
A product priced at zero transfers without a price: a product whose default price is zero does not transfer that price, and the HubSpot product keeps any price it already had. This matters here because a line cannot be priced against a HubSpot product that carries no price.

Setup Requirements

iPaaS.com Configuration

Enable the iPaaS.com Transaction create and update outbound triggers under Outbound Data Flows on the subscription. No automatic transfers occur until they are enabled.
Set Transfer Products as a Prerequisite for Transactions to exactly true if the products behind an order's lines should transfer to HubSpot ahead of the order. Confirm the value reads true and not 1, yes, or on.
Create the HubSpot Owner Id or HubSpot Owner Email custom field on the Transaction module if an owner should be set on the order.
Replace the Currency Code static value on Add HubSpot Order FROM iPaaS.com with the currency the orders are placed in.

HubSpot Configuration

Confirm the connected HubSpot account has Commerce orders available and that the authenticated user can create and edit orders and line items.
Create any HubSpot order or line item property a custom field mapping will target, against the Order or Line Item object type, before enabling that mapping.
Confirm the HubSpot owners referenced by the owner custom fields exist in the connected account.

Authentication and connection setup are covered in HubSpot Installation Instructions and HubSpot Connections and Settings.

Integration Flow

An iPaaS.com transaction create or update, or a manual sync, dispatches the transaction transfer.
The transaction's customer is transferred to HubSpot first when that customer is active in iPaaS.com, and the transaction's company is transferred first when that company is active. Both always run and are not controlled by a setting.
When Transfer Products as a Prerequisite for Transactions reads exactly true, the products behind the transaction's lines are transferred to HubSpot ahead of the order. If a line's SKU does not match an iPaaS.com product, the integration resolves the SKU as a product variant and transfers that variant's parent product instead. A product that cannot be transferred stops the order: the transfer fails and is reported under Dashboard, Integration Monitoring, Error Logs. When the setting does not read exactly true, no product is transferred ahead of the order, and a line resolves its product only if that product is already in HubSpot.
The integration resolves whether the iPaaS.com Transaction is already linked to a HubSpot order. When there is no link, the Add HubSpot Order FROM iPaaS.com collection runs; when a link exists, Update HubSpot Order FROM iPaaS.com runs instead.
The mapped order header values are assembled, including any custom field values.
On Add, the HubSpot order is created from the assembled values and the new HubSpot order id is saved as the external-id link. On Update, the linked HubSpot order is updated in place.
The order is associated with its HubSpot company, or with its HubSpot contact, depending on which the transaction resolves to.
Each line item is written and associated with the order, one line at a time, through the child collection matching the parent that ran.
Only the values the transfer actually has are sent. Properties that are not mapped are never blanked.

Mappings

Add HubSpot Order FROM iPaaS.com (Parent)

iPaaS.com data type: Transaction

This collection creates a new order in HubSpot from an iPaaS.com Transaction. It runs only when the iPaaS.com Transaction has no HubSpot order linked to it yet, so it builds the full order record and lets HubSpot assign the new order id.

This collection carries one mapping that its Update counterpart deliberately does not: Currency Code. The currency is stamped once when the order is created, so a currency corrected in HubSpot afterward survives every subsequent update. This is the one field where the split between the two collections genuinely earns its keep. Every other mapping in this collection is the same as its counterpart in Update HubSpot Order FROM iPaaS.com.

Placeholder value — replace during implementation: the Currency Code mapping ships with a fixed value of USD. Subscribers or their MiSP should replace it with the currency their orders are placed in.

Mapping Type	Source Field (iPaaS.com)	Destination Field (HubSpot)	Description
Field	TransactionNumber	OrderName	Required. The iPaaS.com transaction number, written to the HubSpot order name. This is what identifies the order in the HubSpot interface, so removing this mapping leaves new orders unnamed and hard to recognise. iPaaS.com requires a transaction number on every transaction, so this mapping always carries a value for every record.
Field	Status	FulfillmentStatus	Recommended. The iPaaS.com transaction status, written to the HubSpot order's fulfillment status, which HubSpot describes as the current fulfillment or shipping status of the order. iPaaS.com requires a status on every transaction, and the values it can carry are Pending, Complete, Cancelled, Shipped, Backorder, Refunded, Partially Refunded, Partially Shipped, Awaiting Pickup, Awaiting Payment, On Hold, Processing, Returned, and Draft. The value is passed through as-is, so HubSpot shows the iPaaS.com wording rather than a HubSpot-specific status.
Static	`USD`	CurrencyCode	Recommended. The currency the order was placed in, sent to HubSpot as the fixed value USD. This is the only mapping that exists in this collection and not in Update HubSpot Order FROM iPaaS.com. The effect is deliberate: the currency is stamped once when the order is created and is never re-sent, so a currency corrected in HubSpot afterward is preserved. Subscribers or their MiSP who do not trade in US dollars should change this static value before the first transfer, since the iPaaS.com Transaction's own currency is not read here.
Dynamic Formula	`SpaceportSystemId`	SourceStore	Recommended. Records which iPaaS.com system the order came from, written to the HubSpot order's source store property. This lets orders in HubSpot be told apart by where they originated, which matters when more than one iPaaS.com system feeds the same HubSpot portal. The value is supplied by iPaaS.com automatically and needs no configuration.
Field	TaxAmount	Tax	Optional. The iPaaS.com transaction tax amount, written to the HubSpot order tax. A tax-exempt order carries a tax amount of zero in iPaaS.com, and that zero is written to HubSpot as-is. Remove this mapping if tax is not tracked on HubSpot orders.
Field	DiscountAmount	OrderDiscount	Optional. The iPaaS.com transaction discount amount, written to the HubSpot order discount. This is the order-level discount; discounts recorded against individual lines are handled by the child line item collection. An order carrying no discount has a discount amount of zero in iPaaS.com, and that zero is written to the HubSpot order as-is.
Field	Subtotal	SubtotalPrice	Recommended. The iPaaS.com transaction subtotal, which is the order value before tax and shipping are added. The value is passed through as iPaaS.com holds it, so an order whose goods total is genuinely zero reaches HubSpot with a subtotal of zero rather than an empty subtotal.
Field	Total	TotalPrice	Recommended. The iPaaS.com transaction total, written to the HubSpot order total. This is the headline value most subscribers report on in HubSpot. The total is passed through as iPaaS.com holds it, including a total of zero — a fully discounted or zero-value order reaches HubSpot with a total of zero rather than an empty total.
Field	Status	ExternalOrderStatus	Recommended. The same iPaaS.com transaction status, written a second time to the HubSpot order's external order status. The two status mappings are deliberate. The fulfillment status is the one HubSpot uses to describe where the order is in its own terms, while the external order status preserves the status as the originating system reported it. Keeping both means a subscriber can change the fulfillment status mapping to suit HubSpot's workflow without losing the iPaaS.com value.
Field	ShippingAmount	ShippingCost	Optional. The iPaaS.com transaction shipping amount, written to the HubSpot order shipping cost. An order with free shipping carries a shipping amount of zero in iPaaS.com, and that zero is written to the HubSpot order as-is, so free shipping is recorded as a shipping cost of zero rather than being left blank.
Dynamic Formula	`var customerId = await GetExternalIdAsync(CustomerId, "Customer", SpaceportSystemId); if (customerId == null \|\| customerId == ""){ customerId = await GetExternalIdAsync(CompanyId, "Company", SpaceportSystemId); if (customerId == null \|\| customerId == ""){ customerId = await GetCustomerIdByEmail(EmailAddress); if (customerId == null \|\| customerId == ""){ return null; } else return customerId + "\|customer"; } else return customerId + "\|company"; } else return customerId + "\|customer" ;`	ContactIdOrCompanyId	Required. This is the control field that decides which HubSpot record the order is attached to.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "City");`	BillingAddressCity	Optional. Reads the city from the first address on the iPaaS.com Transaction that is flagged as the primary billing address. Returns empty when the transaction has no address flagged as primary billing.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Country");`	BillingAddressCountry	Optional. Reads the country from the first address on the iPaaS.com Transaction that is flagged as the primary billing address. The value is passed through exactly as iPaaS.com holds it, so whether HubSpot receives a country name or a country code depends on how the source system records it. Returns empty when the transaction has no address flagged as primary billing.
Field	EmailAddress	BillingAddressEmail	Optional. The email address on the iPaaS.com Transaction, written to the order's billing email. This is the transaction's own email address rather than one taken from the billing address record, so it is populated even for a transaction that carries no addresses at all. It is the same value the contact linking formula falls back to when neither a customer nor a company is linked.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "LastName");`	BillingAddressLastname	Optional. Reads the last name from the first address on the iPaaS.com Transaction that is flagged as the primary billing address. Returns empty when the transaction has no address flagged as primary billing.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "FirstName");`	BillingAddressFirstname	Optional. Reads the first name from the first address on the iPaaS.com Transaction that is flagged as the primary billing address. Returns empty when the transaction has no address flagged as primary billing.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "PostalCode");`	BillingAddressPostalCode	Optional. Reads the postal code from the first address on the iPaaS.com Transaction that is flagged as the primary billing address. Returns empty when the transaction has no address flagged as primary billing.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Region");`	BillingAddressState	Optional. Reads the region from the first address on the iPaaS.com Transaction that is flagged as the primary billing address, and writes it to the HubSpot billing state. The iPaaS.com field is called Region because it holds a state, province, or county depending on the country. Returns empty when the transaction has no address flagged as primary billing.
Dynamic Formula	`var address1 = FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Address1"); var address2 = FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Address2"); var address3 = FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Address3"); string address = string.Empty; if(address1 != null) address = address1; if(address2 != null) address += " " + address2; if(address3 != null) address += " " + address3; return address;`	BillingAddressStreet	Optional. The primary billing street address, assembled into the single street field HubSpot holds on an order. The formula reads the three address lines from the first address flagged as the primary billing address and joins the ones that carry a value, separating each with a single space. An address using only the first line produces just that line; an address using all three produces all three in order. When the transaction has no address flagged as primary billing, the mapping returns empty. Change this formula if the address lines should be joined differently, for example with a comma.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Country");`	ShippingAddressCountry	Optional. Reads the country from the first address on the iPaaS.com Transaction that is flagged as the primary shipping address. The value is passed through exactly as iPaaS.com holds it. Returns empty when the transaction has no address flagged as primary shipping.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "City");`	ShippingAddressCity	Optional. Reads the city from the first address on the iPaaS.com Transaction that is flagged as the primary shipping address. Returns empty when the transaction has no address flagged as primary shipping.
Dynamic Formula	`string firstName = FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "FirstName"); string lastName = FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "LastName"); if (!string.IsNullOrWhiteSpace(firstName) && !string.IsNullOrWhiteSpace(lastName)) return $"{firstName} {lastName}"; return !string.IsNullOrWhiteSpace(firstName) ? firstName : lastName;`	ShippingAddressName	Optional. The full name on the transaction's primary shipping address. The formula reads the first name and the last name from the first address flagged as the primary shipping address, and joins them with a space when both are present. When only one is present, that one is returned on its own. When the transaction has no address flagged as primary shipping, the mapping returns empty and no shipping name reaches HubSpot. Unlike the billing side, the shipping name is mapped only as a combined name. There are no separate shipping first name and last name mappings, because the HubSpot order holds the shipping name as a single field.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "PostalCode");`	ShippingAddressPostalCode	Optional. Reads the postal code from the first address on the iPaaS.com Transaction that is flagged as the primary shipping address. Returns empty when the transaction has no address flagged as primary shipping.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Region");`	ShippingAddressState	Optional. Reads the region from the first address on the iPaaS.com Transaction that is flagged as the primary shipping address, and writes it to the HubSpot shipping state. The iPaaS.com field is called Region because it holds a state, province, or county depending on the country. Returns empty when the transaction has no address flagged as primary shipping.
Dynamic Formula	`var address1 = FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Address1"); var address2 = FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Address2"); var address3 = FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Address3"); string address = string.Empty; if(address1 != null) address = address1; if(address2 != null) address += " " + address2; if(address3 != null) address += " " + address3; return address;`	ShippingAddressStreet	Optional. The primary shipping street address, assembled into the single street field HubSpot holds on an order. The formula reads the three address lines from the first address flagged as the primary shipping address and joins the ones that carry a value, separating each with a single space. When the transaction has no address flagged as primary shipping, the mapping returns empty.
Field	Type	Transaction Type	Recommended. The iPaaS.com transaction type, written to a HubSpot custom property named Transaction Type, so the HubSpot order records what kind of transaction produced it. iPaaS.com requires a type on every transaction, and the values it can carry are Order, Shipment, Invoice, Hold, Quote, Ticket, Return, Validated Return, and Job. A subscriber whose iPaaS.com system raises more than one of these against the same HubSpot portal can use this property to tell them apart. This is a custom field mapping, so the HubSpot property must exist before the mapping will work. Create it under Settings, Data Management, Properties as an Order object property, with Single-line text as the field type, and give it a label that matches the iPaaS.com custom field name exactly.
Dynamic Formula	`string firstName = FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "FirstName"); string lastName = FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "LastName"); if (!string.IsNullOrWhiteSpace(firstName) && !string.IsNullOrWhiteSpace(lastName)) return $"{firstName} {lastName}"; return !string.IsNullOrWhiteSpace(firstName) ? firstName : lastName;`	BillingAddressName	Optional. The full name on the transaction's primary billing address. The formula reads the first name and the last name from the first address flagged as the primary billing address, and joins them with a space when both are present. When only one is present, that one is returned on its own. When the transaction has no address flagged as primary billing, the mapping returns empty and no billing name reaches HubSpot.
Field	Id	ExternalOrderId	Recommended. The iPaaS.com Transaction id, written to the HubSpot order as its external order reference. This makes the HubSpot order traceable back to the iPaaS.com transaction it came from, which is useful when reconciling the two systems by hand. This is a data field on the order and is separate from the external-id link the integration maintains to decide whether a transaction creates or updates an order.
Dynamic Formula	`var value = GetCustomFieldValue(CustomFields, "HubSpot Owner Id"); if(!string.IsNullOrWhiteSpace(value)) return value; else{ value = GetCustomFieldValue(CustomFields, "HubSpot Owner Email"); if(!string.IsNullOrWhiteSpace(value)) return await GetOwnerIdByEmail(value); }`	OwnerId	Optional. Sets the HubSpot owner on the order.

ContactIdOrCompanyId

Required. This is the control field that decides which HubSpot record the order is attached to. It returns both an id and the kind of record that id refers to, because a contact and a company are different association types in HubSpot.

The formula works through three attempts in order:

Linked customer: it looks for the HubSpot contact already linked to the transaction's iPaaS.com customer, and returns that id marked as a customer.
Linked company: if there is no linked customer, it looks for the HubSpot company already linked to the transaction's iPaaS.com company, and returns that id marked as a company.
Email search: if neither is linked, it searches HubSpot for a contact with the transaction's email address, and returns that id marked as a customer.

If all three come up empty, the mapping returns nothing and the order is created with no contact or company attached.

Because HubSpot needs the record kind as well as the id, this mapping should only be changed to produce the same combined format the integration expects. It comes up empty less often than it might appear: before the order is written, an unlinked customer or company on the transaction is transferred to HubSpot first, through its own mapping collection.

iPaaS.com requires that every transaction is tied to a customer, a company, or an email address, so the formula always has at least one of the three inputs to work from.

OwnerId

Optional. Sets the HubSpot owner on the order. This mapping is an example: it does nothing until the custom fields it reads are created and populated on the iPaaS.com Transaction module.

The formula tries two sources in order:

HubSpot Owner Id custom field: when it holds a value, that value is used as the owner id directly.
HubSpot Owner Email custom field: when the id field is empty, the email address in this field is resolved to a HubSpot owner id.

When neither carries a value, no owner is set on the order.

To use this mapping as shipped, create the iPaaS.com custom fields HubSpot Owner Id and HubSpot Owner Email on the Transaction module, and populate at least one of them on the transactions being transferred. Setting the owner id is recommended where it is known, because resolving an owner by email address costs an additional lookup against HubSpot and performs less well.

To set the same owner on every order instead, replace the formula with a static owner id, or with a lookup on a fixed email address.

Update HubSpot Order FROM iPaaS.com (Parent)

iPaaS.com data type: Transaction

This collection maintains an order that is already linked to a HubSpot order. It runs only when the iPaaS.com Transaction carries an external-id link, and it applies the mapped values to that existing record.

Apart from the absent Currency Code mapping, this collection ships with the same field set as Add HubSpot Order FROM iPaaS.com. The consequence is worth understanding before going live: every other mapped field is re-applied to the HubSpot order each time the transaction updates. The order name, both statuses, the transaction type, all the totals, the contact or company link, the billing and shipping addresses, and the owner are all re-sent on every transfer, so a change made to any of them by hand in HubSpot is replaced the next time the transaction changes in iPaaS.com.

Placeholder value — replace during implementation: the Update collection ships with the same field set as the Add collection, so every mapped field is re-applied each time the record is updated. Subscribers or their MiSP should adjust the mappings in this collection to match their operations — for example, by removing fields that should be set only when the record is first created.

Mapping Type	Source Field (iPaaS.com)	Destination Field (HubSpot)	Description
Dynamic Formula	`var address1 = FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Address1"); var address2 = FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Address2"); var address3 = FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Address3"); string address = string.Empty; if(address1 != null) address = address1; if(address2 != null) address += " " + address2; if(address3 != null) address += " " + address3; return address;`	BillingAddressStreet	Optional. The primary billing street address, assembled into the single street field HubSpot holds on an order. The formula reads the three address lines from the first address flagged as the primary billing address and joins the ones that carry a value, separating each with a single space. An address using only the first line produces just that line; an address using all three produces all three in order. When the transaction has no address flagged as primary billing, the mapping returns empty. Change this formula if the address lines should be joined differently, for example with a comma. Make the same change in Add HubSpot Order FROM iPaaS.com so that created and updated orders agree.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Country");`	BillingAddressCountry	Optional. Reads the country from the first address on the iPaaS.com Transaction that is flagged as the primary billing address. The value is passed through exactly as iPaaS.com holds it, so whether HubSpot receives a country name or a country code depends on how the source system records it. Returns empty when the transaction has no address flagged as primary billing.
Dynamic Formula	`var customerId = await GetExternalIdAsync(CustomerId, "Customer", SpaceportSystemId); if (customerId == null \|\| customerId == ""){ customerId = await GetExternalIdAsync(CompanyId, "Company", SpaceportSystemId); if (customerId == null \|\| customerId == ""){ customerId = await GetCustomerIdByEmail(EmailAddress); if (customerId == null \|\| customerId == ""){ return null; } else return customerId + "\|customer"; } else return customerId + "\|company"; } else return customerId + "\|customer" ;`	ContactIdOrCompanyId	Required. This is the control field that decides which HubSpot record the order is attached to.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Country");`	ShippingAddressCountry	Optional. Reads the country from the first address on the iPaaS.com Transaction that is flagged as the primary shipping address. The value is passed through exactly as iPaaS.com holds it. Returns empty when the transaction has no address flagged as primary shipping.
Dynamic Formula	`string firstName = FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "FirstName"); string lastName = FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "LastName"); if (!string.IsNullOrWhiteSpace(firstName) && !string.IsNullOrWhiteSpace(lastName)) return $"{firstName} {lastName}"; return !string.IsNullOrWhiteSpace(firstName) ? firstName : lastName;`	ShippingAddressName	Optional. The full name on the transaction's primary shipping address. The formula reads the first name and the last name from the first address flagged as the primary shipping address, and joins them with a space when both are present. When only one is present, that one is returned on its own. When the transaction has no address flagged as primary shipping, the mapping returns empty and the shipping name already on the HubSpot order is left as it is. Unlike the billing side, the shipping name is mapped only as a combined name. There are no separate shipping first name and last name mappings, because the HubSpot order holds the shipping name as a single field.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Region");`	ShippingAddressState	Optional. Reads the region from the first address on the iPaaS.com Transaction that is flagged as the primary shipping address, and writes it to the HubSpot shipping state. The iPaaS.com field is called Region because it holds a state, province, or county depending on the country. Returns empty when the transaction has no address flagged as primary shipping.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "PostalCode");`	ShippingAddressPostalCode	Optional. Reads the postal code from the first address on the iPaaS.com Transaction that is flagged as the primary shipping address. Returns empty when the transaction has no address flagged as primary shipping.
Dynamic Formula	`var address1 = FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Address1"); var address2 = FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Address2"); var address3 = FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "Address3"); string address = string.Empty; if(address1 != null) address = address1; if(address2 != null) address += " " + address2; if(address3 != null) address += " " + address3; return address;`	ShippingAddressStreet	Optional. The primary shipping street address, assembled into the single street field HubSpot holds on an order. The formula reads the three address lines from the first address flagged as the primary shipping address and joins the ones that carry a value, separating each with a single space. When the transaction has no address flagged as primary shipping, the mapping returns empty.
Dynamic Formula	`string firstName = FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "FirstName"); string lastName = FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "LastName"); if (!string.IsNullOrWhiteSpace(firstName) && !string.IsNullOrWhiteSpace(lastName)) return $"{firstName} {lastName}"; return !string.IsNullOrWhiteSpace(firstName) ? firstName : lastName;`	BillingAddressName	Optional. The full name on the transaction's primary billing address. The formula reads the first name and the last name from the first address flagged as the primary billing address, and joins them with a space when both are present. When only one is present, that one is returned on its own. When the transaction has no address flagged as primary billing, the mapping returns empty and the billing name already on the HubSpot order is left as it is.
Field	Id	ExternalOrderId	Recommended. The iPaaS.com Transaction id, written to the HubSpot order as its external order reference. This makes the HubSpot order traceable back to the iPaaS.com transaction it came from. The value never changes for a given transaction, so re-sending it on each update simply confirms the reference. This is a data field on the order and is separate from the external-id link the integration maintains to decide whether a transaction creates or updates an order.
Field	Type	Transaction Type	Recommended. The iPaaS.com transaction type, written to a HubSpot custom property named Transaction Type, so the HubSpot order records what kind of transaction produced it. iPaaS.com requires a type on every transaction, and the values it can carry are Order, Shipment, Invoice, Hold, Quote, Ticket, Return, Validated Return, and Job. Mapping it here as well as in the Add collection means a transaction that changes type in iPaaS.com, for example from Quote to Order, has that change reflected on the HubSpot order. This is a custom field mapping, so the HubSpot property must exist before the mapping will work. Create it under Settings, Data Management, Properties as an Order object property, with Single-line text as the field type, and give it a label that matches the iPaaS.com custom field name exactly.
Dynamic Formula	`var value = GetCustomFieldValue(CustomFields, "HubSpot Owner Id"); if(!string.IsNullOrWhiteSpace(value)) return value; else{ value = GetCustomFieldValue(CustomFields, "HubSpot Owner Email"); if(!string.IsNullOrWhiteSpace(value)) return await GetOwnerIdByEmail(value); }`	OwnerId	Optional. Sets the HubSpot owner on the order.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryShipping == true", "City");`	ShippingAddressCity	Optional. Reads the city from the first address on the iPaaS.com Transaction that is flagged as the primary shipping address. Returns empty when the transaction has no address flagged as primary shipping, in which case the value already on the HubSpot order is left unchanged.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "Region");`	BillingAddressState	Optional. Reads the region from the first address on the iPaaS.com Transaction that is flagged as the primary billing address, and writes it to the HubSpot billing state. The iPaaS.com field is called Region because it holds a state, province, or county depending on the country. Returns empty when the transaction has no address flagged as primary billing.
Field	Status	ExternalOrderStatus	Recommended. The same iPaaS.com transaction status, written a second time to the HubSpot order's external order status. The two status mappings are deliberate. The fulfillment status is the one HubSpot uses to describe where the order is in its own terms, while the external order status preserves the status as the originating system reported it. Keeping both means a subscriber can change the fulfillment status mapping to suit HubSpot's workflow without losing the iPaaS.com value.
Field	DiscountAmount	OrderDiscount	Optional. The iPaaS.com transaction discount amount, written to the HubSpot order discount. This is the order-level discount; discounts recorded against individual lines are handled by the child line item collection. A discount removed from an order in iPaaS.com leaves a discount amount of zero, and that zero is written to the HubSpot order on the next transfer.
Field	Status	FulfillmentStatus	Recommended. The iPaaS.com transaction status, written to the HubSpot order's fulfillment status, which HubSpot describes as the current fulfillment or shipping status of the order. This is the mapping that carries an order's progress through to HubSpot. Most updates to an order exist precisely because its status changed, so this is usually the field a subscriber is watching in HubSpot. iPaaS.com requires a status on every transaction, and the values it can carry are Pending, Complete, Cancelled, Shipped, Backorder, Refunded, Partially Refunded, Partially Shipped, Awaiting Pickup, Awaiting Payment, On Hold, Processing, Returned, and Draft. The value is passed through as-is, so HubSpot shows the iPaaS.com wording rather than a HubSpot-specific status. A fulfillment status changed by hand in HubSpot is replaced on the next transfer.
Field	ShippingAmount	ShippingCost	Optional. The iPaaS.com transaction shipping amount, written to the HubSpot order shipping cost. An order changed to free shipping carries a shipping amount of zero in iPaaS.com, and that zero is written to the HubSpot order on the next transfer, replacing the previous shipping cost.
Field	Subtotal	SubtotalPrice	Recommended. The iPaaS.com transaction subtotal, which is the order value before tax and shipping are added. The value is passed through as iPaaS.com holds it, so a subtotal reduced to zero is written to the HubSpot order as zero. See the note on TotalPrice.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "PostalCode");`	BillingAddressPostalCode	Optional. Reads the postal code from the first address on the iPaaS.com Transaction that is flagged as the primary billing address. Returns empty when the transaction has no address flagged as primary billing.
Field	Total	TotalPrice	Recommended. The iPaaS.com transaction total, written to the HubSpot order total. This is the headline value most subscribers report on in HubSpot, and mapping it here is what keeps it current as an order is amended. The total is passed through as iPaaS.com holds it, including a total of zero. An order whose total is reduced to zero in iPaaS.com, for example after a full refund or a full discount, has its HubSpot total reduced to zero on the next transfer.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "FirstName");`	BillingAddressFirstname	Optional. Reads the first name from the first address on the iPaaS.com Transaction that is flagged as the primary billing address. Returns empty when the transaction has no address flagged as primary billing, in which case the value already on the HubSpot order is left unchanged.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "City");`	BillingAddressCity	Optional. Reads the city from the first address on the iPaaS.com Transaction that is flagged as the primary billing address. Returns empty when the transaction has no address flagged as primary billing, in which case the value already on the HubSpot order is left unchanged.
Dynamic Formula	`return FieldFromFirstMatch(Addresses, "IsPrimaryBilling == true", "LastName");`	BillingAddressLastname	Optional. Reads the last name from the first address on the iPaaS.com Transaction that is flagged as the primary billing address. Returns empty when the transaction has no address flagged as primary billing, in which case the value already on the HubSpot order is left unchanged.
Field	EmailAddress	BillingAddressEmail	Optional. The email address on the iPaaS.com Transaction, written to the order's billing email. This is the transaction's own email address rather than one taken from the billing address record, so it is populated even for a transaction that carries no addresses at all. It is the same value the contact linking formula falls back to when neither a customer nor a company is linked.
Field	TaxAmount	Tax	Optional. The iPaaS.com transaction tax amount, written to the HubSpot order tax. An order whose tax falls to zero in iPaaS.com has its HubSpot tax set to zero on the next transfer, because the value is passed through as-is. Remove this mapping if tax is not tracked on HubSpot orders.
Dynamic Formula	`SpaceportSystemId`	SourceStore	Recommended. Records which iPaaS.com system the order came from, written to the HubSpot order's source store property. This lets orders in HubSpot be told apart by where they originated, which matters when more than one iPaaS.com system feeds the same HubSpot portal. The value is supplied by iPaaS.com automatically and needs no configuration.
Field	TransactionNumber	OrderName	Required. The iPaaS.com transaction number, written to the HubSpot order name. This is what identifies the order in the HubSpot interface. iPaaS.com requires a transaction number on every transaction, so this mapping always carries a value for every record. Because it is re-sent on every update, a transaction number corrected in iPaaS.com is carried through to the HubSpot order name, and an order name edited by hand in HubSpot is replaced on the next transfer.

ContactIdOrCompanyId

The formula works through three attempts in order:

Linked customer: it looks for the HubSpot contact already linked to the transaction's iPaaS.com customer, and returns that id marked as a customer.
Linked company: if there is no linked customer, it looks for the HubSpot company already linked to the transaction's iPaaS.com company, and returns that id marked as a company.
Email search: if neither is linked, it searches HubSpot for a contact with the transaction's email address, and returns that id marked as a customer.

If all three come up empty, the mapping returns nothing and the order is updated with no contact or company attached.

This mapping is recalculated on every update, which is what allows an order created before its customer reached HubSpot to be linked on a later transfer. It also means that moving a transaction to a different customer in iPaaS.com re-points the HubSpot order on the next update.

Because HubSpot needs the record kind as well as the id, this mapping should only be changed to produce the same combined format the integration expects. Before the order is written, an unlinked customer or company on the transaction is transferred to HubSpot first, through its own mapping collection.

OwnerId

Optional. Sets the HubSpot owner on the order. This mapping is an example: it does nothing until the custom fields it reads are created and populated on the iPaaS.com Transaction module.

The formula tries two sources in order:

HubSpot Owner Id custom field: when it holds a value, that value is used as the owner id directly.
HubSpot Owner Email custom field: when the id field is empty, the email address in this field is resolved to a HubSpot owner id.

When neither carries a value, the owner already on the HubSpot order is left as it is rather than being cleared. This means an owner assigned by hand in HubSpot survives later updates, as long as the iPaaS.com custom fields stay empty.

To maintain the same owner on every order instead, replace the formula with a static owner id, or with a lookup on a fixed email address.

Add HubSpot Order Line Item FROM iPaaS.com (Child)

iPaaS.com data type: Transaction Line

This collection creates the HubSpot line items for an order that is being created. Each iPaaS.com transaction line becomes one HubSpot line item, carrying the product reference, the SKU, the name, the description, the quantity, and the money on the line.

It cannot be triggered directly. It runs as part of Add HubSpot Order FROM iPaaS.com, when the order and its line items are being created. Which collection runs follows entirely from the link state of the transaction, not from a setting.

This collection performs no prerequisite handling of its own. This is a real difference from the parent collections, which transfer the customer, the company, and optionally the products before the order is written. The product behind a line is therefore transferred by the parent, and only when Transfer Products as a Prerequisite for Transactions reads exactly true. When that setting is not enabled, a line's product reference resolves only if the product is already in HubSpot; otherwise the line item is written without one.

Mapping Type	Source Field (iPaaS.com)	Destination Field (HubSpot)	Description
Dynamic Formula	`//Use transaction line description return Description; //Use iPaaS parent product description var hsProductId = await GetProductIdBySku(Sku); if(hsProductId == null \|\| hsProductId == ""){ var iPaaSProductId = await ParentIdFromSku(Sku); if(iPaaSProductId != null && iPaaSProductId != ""){ return await GetiPaaSProductDescriptionById(iPaaSProductId); } } return Description;`	Description	Optional. The description shown on the HubSpot line item. This mapping ships with two alternatives in the formula, and the first one is the one that runs. As shipped, the transaction line's own description is returned. Below it sits a second, inactive alternative that resolves the line's SKU to its iPaaS.com parent product and returns the parent product's description instead, which is useful where transaction lines carry terse descriptions and the product catalogue carries fuller ones. To switch to the parent-product behaviour, remove the first return statement from the formula in the iPaaS.com mapping interface so that the second block runs.
Dynamic Formula	`DiscountAmount > (decimal)0.0 && Qty > (decimal)0.0 ? DiscountAmount / Qty : null`	Discount	Optional. The per-unit discount on the line, written to the HubSpot line item discount. HubSpot's line item discount is a per-unit value that it multiplies by the line quantity, so the integration divides the iPaaS.com line discount amount by the line quantity before sending it. Do not re-point this mapping at the raw discount amount: HubSpot would multiply that line total by the quantity and take off far more than the line was actually discounted. This is the line-level discount; a discount applied to the order as a whole is handled by the parent transaction collection. A discount of zero is sent as no value at all, so an undiscounted line reaches HubSpot with no discount set.
Dynamic Formula	`return null; //DiscountPercent > (decimal)0.0 ? DiscountPercent : null`	DiscountPercentage	Optional. This mapping intentionally does not transfer a value. HubSpot rejects any line item that carries both a discount amount and a discount percentage, and fails the entire order transfer when that happens. The iPaaS.com discount amount is the value the integration sends, so the percentage is deliberately not transferred. Do not re-point this mapping at the iPaaS.com discount percentage: a line discounted by a percentage carries both values, and sending both makes HubSpot reject the whole order. The exact error is listed in the HubSpot Error Messages documentation.
Dynamic Formula	`EstimatedTaxAmount > (decimal)0.0 ? EstimatedTaxAmount : null`	TaxAmount	Optional. The tax recorded against this line, written to the HubSpot line item tax amount. The iPaaS.com source field is the estimated tax amount, which is the figure the source system calculated for the line rather than a settled tax figure. Where HubSpot line items are used for tax reporting, confirm that an estimate is acceptable for that purpose. A tax amount of zero is sent as no value at all, so a tax-exempt line reaches HubSpot with no tax set.
Dynamic Formula	`UnitPrice > (decimal)0.0 ? UnitPrice : null`	Price	Recommended. The per-unit price of the line, written to the HubSpot line item price. HubSpot treats the line item price as a unit price and works out the line total itself, as (price minus discount) multiplied by quantity. The integration therefore sends the iPaaS.com per-unit price, not the line's extended total: sending the extended total would let HubSpot apply the quantity a second time and overstate the order. A price of zero is sent as no value at all, so a free line reaches HubSpot with no price set.
Dynamic Formula	`ExtendedPrice > (decimal)0.0 ? ExtendedPrice : null`	Amount	Recommended. The total cost of the line, written to the HubSpot line item amount. This mapping reads the same iPaaS.com extended price as the Price mapping, so both HubSpot properties carry the line's extended price by default. That is a reasonable starting point, since the extended price is the line total. Where a unit price and a line total should differ in HubSpot, change the Price mapping to read the iPaaS.com unit price and leave this one reading the extended price. An amount of zero is sent as no value at all.
Dynamic Formula	`TaxPercent > (decimal)0.0 ? TaxPercent : null`	TaxRate	Optional. The tax rate applied to this line, written to the HubSpot line item tax rate. This mapping and the TaxAmount mapping both transfer by default, so a taxed line arrives in HubSpot with both the rate and the amount. Remove whichever one is not needed on HubSpot line items. A rate of zero is sent as no value at all.
Dynamic Formula	`//Use transaction line Sku return Sku; //Use iPaaS parent product Sku var hsProductId = await GetProductIdBySku(Sku); if(hsProductId == null \|\| hsProductId == ""){ var iPaaSProductId = await ParentIdFromSku(Sku); if(iPaaSProductId != null && iPaaSProductId != ""){ return await GetiPaaSProductSkuById(iPaaSProductId); } } return Sku;`	Name	Recommended. The name shown on the HubSpot line item.
Dynamic Formula	`Qty > (decimal)0.0 ? Qty : null`	Quantity	Recommended. How many units of the product the line covers, written to the HubSpot line item quantity. The formula sends the quantity only when it is greater than zero; a quantity of zero is sent as no value at all. A line that legitimately carries a zero quantity therefore reaches HubSpot with no quantity set rather than a quantity of zero. This is the formula's doing, and it can be changed: subscribers or their MiSP who need zero quantities represented in HubSpot can edit this mapping to return the quantity unconditionally, and should make the same change in Update HubSpot Order Line Item FROM iPaaS.com so that created and updated line items agree.
Dynamic Formula	`//Use transaction line Sku return Sku; //Use iPaaS parent product Sku var hsProductId = await GetProductIdBySku(Sku); if(hsProductId == null \|\| hsProductId == ""){ var iPaaSProductId = await ParentIdFromSku(Sku); if(iPaaSProductId != null && iPaaSProductId != ""){ return await GetiPaaSProductSkuById(iPaaSProductId); } } return Sku;`	Sku	Recommended. The SKU shown on the HubSpot line item.
Dynamic Formula	`var hsProductId = await GetProductIdBySku(Sku); if(hsProductId == null \|\| hsProductId == ""){ var iPaaSProductId = await ParentIdFromSku(Sku); if(iPaaSProductId != null && iPaaSProductId != ""){ return await GetExternalIdAsync(iPaaSProductId, "Product", SpaceportSystemId); } } return hsProductId;`	ProductId	Required. This mapping links the HubSpot line item to a HubSpot product record, which is what turns a line of text into a line item HubSpot can report on alongside the rest of the product catalogue.

Name

Recommended. The name shown on the HubSpot line item. Without it, line items appear unlabelled on the HubSpot order.

This mapping ships with the same two alternatives as the SKU mapping, and the first one is the one that runs. As shipped, the transaction line's SKU is used as the line item name. Below it sits a second, inactive alternative that resolves the SKU to its iPaaS.com parent product and returns the parent product's SKU instead.

Using a SKU as the name is a starting point rather than a finished presentation. Subscribers or their MiSP who would rather see a product name on the HubSpot order should change this mapping to read a more descriptive source from the transaction line or its product.

To switch to the parent-product behaviour, remove the first return statement from the formula in the iPaaS.com mapping interface so that the second block runs.

Sku

Recommended. The SKU shown on the HubSpot line item.

This mapping ships with two alternatives in the formula, and the first one is the one that runs. As shipped, the transaction line's own SKU is returned, so the HubSpot line item shows exactly what the iPaaS.com line quotes. Below it sits a second, inactive alternative that resolves the SKU to its iPaaS.com parent product and returns the parent product's SKU instead.

To switch to the parent-product behaviour, remove the first return statement from the formula in the iPaaS.com mapping interface so that the second block runs. The choice matters only for transactions that quote variant SKUs: the shipped behaviour shows the variant's SKU, while the alternative shows the parent's. Where a line's SKU should match the product the line item is attached to, the alternative is the closer fit, because the product reference itself resolves to the parent.

iPaaS.com requires that a line's SKU resolves to an existing product or variant when the line's type is Product, so this mapping carries a value for every product line.

ProductId

Required. This mapping links the HubSpot line item to a HubSpot product record, which is what turns a line of text into a line item HubSpot can report on alongside the rest of the product catalogue.

The formula resolves the product in two steps:

Direct SKU match: it searches HubSpot for a product carrying the transaction line's SKU, and uses that product's id.
Variant fallback: if no HubSpot product carries that SKU, the SKU is treated as an iPaaS.com variant. The formula finds that variant's parent product and uses the HubSpot product linked to the parent instead.

The fallback is why a transaction line that quotes a variant SKU still attaches to the right HubSpot product: iPaaS.com tracks variants as records in their own right, while the HubSpot catalogue holds the parent product.

If neither step resolves, the line item is created without a product reference. It still carries the name, SKU, and description as text. Whether the product exists in HubSpot at all is largely governed by the parent transaction collection, which transfers the products behind the lines beforehand when the Transfer Products as a Prerequisite for Transactions subscription setting is set to the value true. This line item collection performs no prerequisite handling of its own.

Update HubSpot Order Line Item FROM iPaaS.com (Child)

iPaaS.com data type: Transaction Line

This collection maintains the HubSpot line items of an order that is already linked. It ships with the same eleven mappings as Add HubSpot Order Line Item FROM iPaaS.com, so a line item is built the same way whether it is being created or updated. The behaviour when a value is emptied differs, however, and the field notes below are specific to this collection: because only the values the transfer actually has are sent, a value cleared in iPaaS.com leaves the previous value in place on the HubSpot line item rather than clearing it.

It cannot be triggered directly. It runs as part of Update HubSpot Order FROM iPaaS.com, when an existing order's line items are being maintained.

Placeholder value — replace during implementation: the Update HubSpot Order Line Item FROM iPaaS.com collection ships with the same field set as Add HubSpot Order Line Item FROM iPaaS.com, so every mapped field is re-applied each time the line item is updated. Subscribers or their MiSP should adjust the mappings in this collection to match their operations — for example, by removing fields that should be set only when the line item is first created.

Subscribers or their MiSP who want a line item field set at creation and left alone afterward can achieve that by removing the mapping from Update HubSpot Order Line Item FROM iPaaS.com. A change intended to apply to both creation and update must be made in both collections.

Mapping Type	Source Field (iPaaS.com)	Destination Field (HubSpot)	Description
Dynamic Formula	`DiscountAmount > (decimal)0.0 && Qty > (decimal)0.0 ? DiscountAmount / Qty : null`	Discount	Optional. The per-unit discount on the line, written to the HubSpot line item discount. HubSpot's line item discount is a per-unit value that it multiplies by the line quantity, so the integration divides the iPaaS.com line discount amount by the line quantity before sending it. Do not re-point this mapping at the raw discount amount: HubSpot would multiply that line total by the quantity and take off far more than the line was actually discounted. This is the line-level discount; a discount applied to the order as a whole is handled by the parent transaction collection. A discount of zero is sent as no value at all, so a discount removed from a line in iPaaS.com leaves the previous discount value on the HubSpot line item.
Dynamic Formula	`ExtendedPrice > (decimal)0.0 ? ExtendedPrice : null`	Amount	Recommended. The total cost of the line, written to the HubSpot line item amount. This mapping reads the same iPaaS.com extended price as the Price mapping, so both HubSpot properties carry the line's extended price by default. That is a reasonable starting point, since the extended price is the line total. Where a unit price and a line total should differ in HubSpot, change the Price mapping to read the iPaaS.com unit price and leave this one reading the extended price. An amount of zero is sent as no value at all, so the previous HubSpot amount is kept.
Dynamic Formula	`EstimatedTaxAmount > (decimal)0.0 ? EstimatedTaxAmount : null`	TaxAmount	Optional. The tax recorded against this line, written to the HubSpot line item tax amount. The iPaaS.com source field is the estimated tax amount, which is the figure the source system calculated for the line rather than a settled tax figure. Where HubSpot line items are used for tax reporting, confirm that an estimate is acceptable for that purpose. A tax amount of zero is sent as no value at all, so a line that becomes tax-exempt keeps its previous tax value on the HubSpot line item.
Dynamic Formula	`return null; //DiscountPercent > (decimal)0.0 ? DiscountPercent : null`	DiscountPercentage	Optional. This mapping intentionally does not transfer a value. HubSpot rejects any line item that carries both a discount amount and a discount percentage, and fails the entire order transfer when that happens. The iPaaS.com discount amount is the value the integration sends, so the percentage is deliberately not transferred. Do not re-point this mapping at the iPaaS.com discount percentage: a line discounted by a percentage carries both values, and sending both makes HubSpot reject the whole order. The exact error is listed in the HubSpot Error Messages documentation.
Dynamic Formula	`//Use transaction line Sku return Sku; //Use iPaaS parent product Sku var hsProductId = await GetProductIdBySku(Sku); if(hsProductId == null \|\| hsProductId == ""){ var iPaaSProductId = await ParentIdFromSku(Sku); if(iPaaSProductId != null && iPaaSProductId != ""){ return await GetiPaaSProductSkuById(iPaaSProductId); } } return Sku;`	Name	Recommended. The name shown on the HubSpot line item.
Dynamic Formula	`//Use transaction line Sku return Sku; //Use iPaaS parent product Sku var hsProductId = await GetProductIdBySku(Sku); if(hsProductId == null \|\| hsProductId == ""){ var iPaaSProductId = await ParentIdFromSku(Sku); if(iPaaSProductId != null && iPaaSProductId != ""){ return await GetiPaaSProductSkuById(iPaaSProductId); } } return Sku;`	Sku	Recommended. The SKU shown on the HubSpot line item.
Dynamic Formula	`Qty > (decimal)0.0 ? Qty : null`	Quantity	Recommended. How many units of the product the line covers, written to the HubSpot line item quantity. Mapping it here is what keeps the quantity current when a line is amended in iPaaS.com. The formula sends the quantity only when it is greater than zero; a quantity of zero is sent as no value at all. This matters more on update than on create: because the mapping sends nothing, a line whose quantity is reduced to zero in iPaaS.com keeps its previous quantity on the HubSpot line item rather than being reduced to zero. This is the formula's doing, and it can be changed: subscribers or their MiSP who need zero quantities represented in HubSpot can edit this mapping to return the quantity unconditionally, and should make the same change in Add HubSpot Order Line Item FROM iPaaS.com so that created and updated line items agree.
Dynamic Formula	`UnitPrice > (decimal)0.0 ? UnitPrice : null`	Price	Recommended. The per-unit price of the line, written to the HubSpot line item price. HubSpot treats the line item price as a unit price and works out the line total itself, as (price minus discount) multiplied by quantity. The integration therefore sends the iPaaS.com per-unit price, not the line's extended total: sending the extended total would let HubSpot apply the quantity a second time and overstate the order. A price of zero is sent as no value at all, so a price cleared in iPaaS.com leaves the previous price on the HubSpot line item.
Dynamic Formula	`var hsProductId = await GetProductIdBySku(Sku); if(hsProductId == null \|\| hsProductId == ""){ var iPaaSProductId = await ParentIdFromSku(Sku); if(iPaaSProductId != null && iPaaSProductId != ""){ return await GetExternalIdAsync(iPaaSProductId, "Product", SpaceportSystemId); } } return hsProductId;`	ProductId	Required. This mapping links the HubSpot line item to a HubSpot product record, which is what turns a line of text into a line item HubSpot can report on alongside the rest of the product catalogue.
Dynamic Formula	`TaxPercent > (decimal)0.0 ? TaxPercent : null`	TaxRate	Optional. The tax rate applied to this line, written to the HubSpot line item tax rate. This mapping and the TaxAmount mapping both transfer by default, so a taxed line arrives in HubSpot with both the rate and the amount. Remove whichever one is not needed on HubSpot line items, in this collection and in the Add collection. A rate of zero is sent as no value at all, so the previous HubSpot value is kept.
Dynamic Formula	`//Use transaction line description return Description; //Use iPaaS parent product description var hsProductId = await GetProductIdBySku(Sku); if(hsProductId == null \|\| hsProductId == ""){ var iPaaSProductId = await ParentIdFromSku(Sku); if(iPaaSProductId != null && iPaaSProductId != ""){ return await GetiPaaSProductDescriptionById(iPaaSProductId); } } return Description;`	Description	Optional. The description shown on the HubSpot line item. This mapping ships with two alternatives in the formula, and the first one is the one that runs. As shipped, the transaction line's own description is returned. Below it sits a second, inactive alternative that resolves the line's SKU to its iPaaS.com parent product and returns the parent product's description instead, which is useful where transaction lines carry terse descriptions and the product catalogue carries fuller ones. To switch to the parent-product behaviour, remove the first return statement from the formula in the iPaaS.com mapping interface so that the second block runs. Make the same change in Add HubSpot Order Line Item FROM iPaaS.com so that created and updated line items agree.

Name

Recommended. The name shown on the HubSpot line item. Without it, line items appear unlabelled on the HubSpot order.

Because this mapping is re-applied on every update, a line item name edited by hand in HubSpot is replaced the next time the transaction transfers.

Sku

Recommended. The SKU shown on the HubSpot line item.

To switch to the parent-product behaviour, remove the first return statement from the formula in the iPaaS.com mapping interface so that the second block runs. Make the same change in Add HubSpot Order Line Item FROM iPaaS.com, otherwise a line item is created with one SKU and changed to the other on its first update.

iPaaS.com requires that a line's SKU resolves to an existing product or variant when the line's type is Product, so this mapping carries a value for every product line.

ProductId

Required. This mapping links the HubSpot line item to a HubSpot product record, which is what turns a line of text into a line item HubSpot can report on alongside the rest of the product catalogue.

The formula resolves the product in two steps:

Direct SKU match: it searches HubSpot for a product carrying the transaction line's SKU, and uses that product's id.
Variant fallback: if no HubSpot product carries that SKU, the SKU is treated as an iPaaS.com variant. The formula finds that variant's parent product and uses the HubSpot product linked to the parent instead.

Because this mapping is recalculated on every update, a line item created before its product reached HubSpot is linked on a later transfer once the product exists. If neither step resolves, the line item's product reference is left unresolved and the line still carries its name, SKU, and description as text.

Whether the product exists in HubSpot at all is largely governed by the parent transaction collection, which transfers the products behind the lines beforehand when the Transfer Products as a Prerequisite for Transactions subscription setting is set to the value true. This line item collection performs no prerequisite handling of its own.

Error Handling

The errors these collections can raise are catalogued, with their causes and resolutions, in HubSpot Error Messages. Rather than repeat them here, the entries most relevant to order transfers are:

HubSpot API Communication: covers the messages raised when HubSpot rejects or cannot receive an order or line item write, including the rate limit case. At the time this documentation was written, the integration does not wait and retry when HubSpot throttles it, so a throttled transfer fails and must be re-run.
Product could not be transferred before the transaction: raised against an order whose line references a product SKU that does not yet exist in HubSpot, when the product's own prerequisite transfer failed. The product's underlying error is reported separately in the Error Logs; resolve that error, then re-sync the transaction.
Product could not be transferred before the transaction after resolving a variant SKU: the same case, where the line's SKU resolved to a variant and the variant's parent product failed to transfer.

Errors raised by these collections are visible under Dashboard, Integration Monitoring, Error Logs.

Testing & Validation

Test Scenarios

Create a new iPaaS.com Transaction that has never been transferred, then manually sync it by its iPaaS.com Transaction id. Confirm a new HubSpot order is created, that the iPaaS.com Transaction now carries the HubSpot order id as its external-id link, and that one HubSpot line item exists for each transaction line.
Change a total or the transaction number on that same transaction and re-sync. Confirm the existing HubSpot order is updated in place and no second order appears.
Edit a mapped value by hand in HubSpot — the order name, for example — then re-sync the transaction. Confirm the iPaaS.com value replaces the hand-made change. Repeat on a HubSpot property that is not mapped and confirm it is left as it is.
Change the Currency Code in HubSpot on an already-transferred order and re-sync. Confirm the corrected currency survives, because the Update collection does not re-send it.
Flag an address on the iPaaS.com Transaction as primary billing and another as primary shipping, then re-sync. Confirm both reach the HubSpot order. Remove the primary billing flag and confirm no billing address is sent.
Populate HubSpot Owner Id with a real HubSpot owner id and re-sync. Confirm the order owner is set. Clear it, populate HubSpot Owner Email instead, and confirm the owner resolves by email. Clear both and confirm the existing owner is left unchanged rather than cleared.
With Transfer Products as a Prerequisite for Transactions set to exactly true, transfer a transaction whose line references a product not yet in HubSpot. Confirm the product transfers first and the line resolves to it. Repeat with the setting reading 1 and confirm the prerequisite silently does not run and the line item is written without a product reference.
Transfer a transaction whose line carries a variant SKU. Confirm the variant's parent product is transferred and referenced.
Transfer a transaction with a line whose quantity or price is zero. Confirm the field reaches HubSpot unset on creation, and on a later update confirm the HubSpot line item keeps its previous value rather than being reduced to zero.
Remove a line from an already-transferred transaction and re-sync. Confirm the corresponding HubSpot line item remains on the order.
Transfer a transaction whose customer and company have not yet reached HubSpot, then transfer them and re-sync. Confirm the order's contact or company association is picked up on the update.

Validation Checklist

The iPaaS.com Transaction create and update outbound triggers are subscribed under Outbound Data Flows.
All four collections are enabled.
The Currency Code static value has been replaced with the currency the orders are placed in.
Transfer Products as a Prerequisite for Transactions reads exactly true if products should transfer ahead of orders.
A first transfer creates a HubSpot order and records the external-id link.
A second transfer of the same transaction updates it rather than creating a duplicate.
Properties left unmapped on the HubSpot order are not blanked by a transfer.
The mappings in the Update collections have been reviewed against the operation's needs, and any field that should be create-only has been removed from them.
Every HubSpot property targeted by a custom field mapping exists against the Order or Line Item object type.
The owner is set only when one of the owner custom fields carries a value.
Only the primary billing and primary shipping addresses reach HubSpot.
The HubSpot account was checked for existing orders before a bulk transaction load.
Errors appear under Dashboard, Integration Monitoring, Error Logs.

Additional Notes

At the time this documentation was written, this direction does not search HubSpot for an existing order before creating one. An iPaaS.com Transaction with no link produces a new HubSpot order even when an equivalent order already exists there. Subscribers or their MiSP should link or reconcile pre-existing HubSpot orders before the first outbound transfer, or expect to merge duplicates in HubSpot afterward.
At the time this documentation was written, the shipped line item formulas do not send a value of zero. The quantity, price, amount, discount, and tax mappings send a value only when it is greater than zero, so a line that legitimately carries a zero quantity or a zero price reaches HubSpot with that field unset, and on an update the value already on the HubSpot line item is left as it is rather than being reduced to zero. This is the formula's doing rather than a restriction of the integration: subscribers or their MiSP who need a zero recorded in HubSpot can edit the formula on the affected mapping to return the value unconditionally, and should make the same change in both line item collections so that created and updated line items agree.
At the time this documentation was written, a line removed in iPaaS.com stays on the HubSpot order. The line item collections write the lines they are given and do not remove HubSpot line items that no longer have a matching iPaaS.com transaction line.
At the time this documentation was written, only one address of each kind transfers, because the HubSpot order holds a single billing address and a single shipping address.
At the time this documentation was written, the Transfer Products as a Prerequisite for Transactions setting is recognised only when it reads exactly true. Any other value silently disables product prerequisites rather than reporting a configuration error.
The order currency is not corrected after creation. At the time this documentation was written, an order created with the wrong currency keeps that currency in HubSpot unless it is changed there by hand, because the Update collection does not map the currency.
The following are out of scope for these collections: payments, taxes as separate records, tracking, and notes, which the iPaaS.com Transaction can carry but which are not mapped to HubSpot; line-level shipping addresses, gift card details, coupons, and line discounts as separate records, which the iPaaS.com transaction line can carry but which are not mapped; and HubSpot orders into iPaaS.com, as this integration does not transfer orders inbound — an order created in HubSpot stays in HubSpot.

iPaaS.com to HubSpot Order Mapping Documentation

Summary

ID Format

Manual Sync ID Format

External ID Format

Deleted Record Support

Custom Field Support

Mapping Collection Status

Duplicate or Conflicting Mappings

Supported Child Collections

System Caveats

HubSpot Caveats

iPaaS.com Caveats

Setup Requirements

iPaaS.com Configuration

HubSpot Configuration

Integration Flow

Mappings

Add HubSpot Order FROM iPaaS.com (Parent)

ContactIdOrCompanyId

OwnerId

Update HubSpot Order FROM iPaaS.com (Parent)

ContactIdOrCompanyId

OwnerId

Add HubSpot Order Line Item FROM iPaaS.com (Child)

Name

Sku

ProductId

Update HubSpot Order Line Item FROM iPaaS.com (Child)

Name

Sku

ProductId

Error Handling

Testing & Validation

Test Scenarios

Validation Checklist

Additional Notes

Related Documents