Summary

A HubSpot company can be transferred into iPaaS.com as an iPaaS.com Company, creating the record when it does not yet exist and updating it when it does. A single company transfer also carries the company's address and its contact and company associations, because both are child collections of the company. This is the inbound half of a bi-directional company sync; its outbound counterparts are Add HubSpot Company FROM iPaaS.com and Update HubSpot Company FROM iPaaS.com.

ID Format

Manual Sync ID Format

Enter the HubSpot company id on the iPaaS.com Manual Sync page to transfer that company into iPaaS.com. The address and association child collections have no Manual Sync id of their own — they transfer only as part of their parent company, using that same HubSpot company id.

External ID Format

The HubSpot company id is recorded as the external-id link on the iPaaS.com Company, so later transfers update the same record rather than creating another one.

The two child collections record a composite link, because a single HubSpot company can produce more than one iPaaS.com child record:

Company Address: the link joins the HubSpot company id to the id of the mapping collection that produced the address, separated by a pipe character. A HubSpot company carries only one address, but a subscription can define more than one address mapping collection against it, so including the collection id keeps each mapping collection's address separately identifiable on the same company.
Company Association: the link joins four values with pipe characters — the HubSpot id of the record at the other end of the association, the literal owning object type company, the HubSpot id of the owning company, and the type of the associated record, either contact or company. Recording both ends of the association keeps each association on a company separately identifiable.

Deleted Record Support

Deleted records are not supported. Deleting a company in HubSpot does not delete or deactivate the company in iPaaS.com, delete mappings are not included in the default templates, and deletions do not propagate in any form. The same applies to the child collections: removing an address or an association in HubSpot does not remove the linked iPaaS.com Company Address or Company Relationship. Removing a record in iPaaS.com is a manual action performed under a supervised process.

Custom Field Support

Custom fields are supported on Add/Update HubSpot Company TO iPaaS.com. A HubSpot company property beyond the standard set is read with a formula that searches for the property by its HubSpot property label, and the value is written to an iPaaS.com Company custom field. Two custom-field mappings ship in the default template — HubSpot Owner Id and HubSpot Owner Email. Create the matching custom fields on the iPaaS.com Company module before relying on them, or the mappings have nowhere to write.

To bring an additional HubSpot company property into iPaaS.com, add a Dynamic Formula mapping that looks the property up by its HubSpot property label and targets the iPaaS.com custom field it should be written to.

Custom fields are not supported on Add/Update HubSpot Company Address TO iPaaS.com. The integration does not read HubSpot custom properties into that collection and does not expose custom-field destinations on it.

On Add/Update HubSpot Company Association TO iPaaS.com, HubSpot custom properties are not supported as source fields — a HubSpot property cannot be used as a source on an association record. The iPaaS.com Company Relationship does accept custom fields as destinations, and the default template uses two of them, Name and Company Relationship Type. Adding further mappings to iPaaS.com Relationship custom fields is the supported way to capture more of an association's detail, and it applies to this direction only.

Mapping Collection Status

Status: Enabled. The parent company collection and both child collections ship with the HubSpot template and are enabled.

Trigger Events: HubSpot companies are not transferred to iPaaS.com automatically through created or updated webhooks. They transfer on a schedule using a record polling approach: after each polling event, iPaaS.com saves the current time to the HubSpot subscription, and the next polling event uses that saved timestamp to request only the companies modified since then. Polling is typically configured in the iPaaS.com event system using the Webhook (poll request) event type, and a company poll request may also be sent manually. The company scopes available are company/created, company/updated, company/deleted, and company/poll; the scheduled poll is the mechanism that actually moves records, and, at the time this documentation was written, company/deleted is advertised but is not implemented, so company deletions do not reach iPaaS.com. Subscribers or their MiSP should configure a polling schedule that matches how quickly company changes need to reach iPaaS.com. The child collections have no trigger of their own and run whenever their parent company transfers, by either method.

Duplicate or Conflicting Mappings

No duplicate check is performed when a company is transferred between HubSpot and iPaaS.com, because names, email addresses, and website addresses are used inconsistently across HubSpot company records.

The two platforms disagree about duplicates, and this is the practical consequence:

iPaaS.com rejects duplicates: the iPaaS.com Company API requires the combination of company Name and Department to be unique when a company is created. Because Department is not mapped in this collection, this behaves as a uniqueness requirement on Name alone. A name collision surfaces as a transfer failure rather than a merge.
HubSpot allows duplicates: HubSpot permits companies with the same name, and HubSpot does not deduplicate companies created through an API. Where similar companies exist on both platforms, a company can be created in HubSpot that already exists in iPaaS.com.

If a merge is performed in HubSpot, the resulting record should be the one linked to iPaaS.com so it remains usable for future transfers. Subscribers or their MiSP should consult on a naming approach that keeps iPaaS.com company names unique.

The opposite-direction collections that operate on the same entity are Add HubSpot Company FROM iPaaS.com and Update HubSpot Company FROM iPaaS.com. The equivalent children of the Contact collection — Add/Update HubSpot Contact Address TO iPaaS.com and Add/Update HubSpot Contact Association TO iPaaS.com — import the address and associations held on a HubSpot contact rather than on a company, so they do not overlap with the children documented here. Review the filters and Add/Update settings on both directions, and decide which system is the source of truth for a given field, before enabling a bi-directional company sync.

Unmapped Field Overwrite Risk

Warning. A transfer into iPaaS.com is written by the iPaaS.com platform, which replaces the destination record with the values the mapping collection supplies. Any iPaaS.com field that a collection does not map is therefore cleared each time that collection runs. When using a bi-directional sync it is important to map every value that must be preserved.

The clearest example: HubSpot has no company email property by default, so there is no HubSpot value to send. An email address held on the iPaaS.com Company is removed when that company is updated from HubSpot, unless a mapping preserves it.

The iPaaS.com Company fields not mapped by the default template, and therefore at risk:

Email Address: HubSpot has no default company email property to supply a value.
Department: also participates in the iPaaS.com company uniqueness requirement.
Fax Number
Account Number
Tax Id Number

The iPaaS.com Company Address fields not mapped by the default template:

Type: the address type descriptor.
Name: the address name or label.
Address3: the third street address line. HubSpot holds only two street lines and sends nothing for a third.
IsPrimaryShipping: whether the address is the company's primary shipping address.

The iPaaS.com Company Relationship fields not mapped by the default template:

StartDate: the date the relationship began.
EndDate: the date the relationship ended.
IsPrimary: whether this is the company's primary relationship.

A standard HubSpot company address has no equivalent for any of the address fields above, and a HubSpot association carries no start date, end date, or primary flag, so none of these values has a HubSpot source to supply it.

Mitigation. For each field that is maintained in iPaaS.com, add a mapping for that field on the collection concerned and use the DestinationValue source, which reads the value already stored on the iPaaS.com record and writes it back unchanged. For example, map DestinationValue.EmailAddress to the iPaaS.com Company Email Address field and the current value is retained instead of cleared. Apply the same approach to any other field that must survive an inbound update. Subscribers or their MiSP should plan these mappings deliberately before enabling a bi-directional transfer.

Supported Child Collections

Add/Update HubSpot Company Address TO iPaaS.com: brings the company's single HubSpot address into iPaaS.com as a company address. HubSpot holds one address per company, so the template targets the primary billing address.
Add/Update HubSpot Company Association TO iPaaS.com: brings the company's HubSpot contact and company associations into iPaaS.com as company relationships.

Both children run as part of the parent company's transfer and have no children of their own.

System Caveats

HubSpot Caveats

Single address: standard HubSpot company fields hold a single address entry. The child address collection reads that one address; HubSpot cannot supply multiple company addresses, and a HubSpot company cannot carry a separate shipping address alongside a billing address.
No person name is available: a HubSpot company record has no first or last name property, so the recipient name on the imported address is derived from the company name rather than from a real contact person.
Address values are plain text: HubSpot does not validate the address and does not standardize country or state values. Whatever text is present on the company is what transfers.
Company category property: the HubSpot property named in the Company Category Field Name subscription setting supplies the company's category. It must be created in HubSpot beforehand as a Dropdown select property on the Company object, with at least one option defined. Leaving the setting empty fully disables company category processing, including the transfer of dependent categories.
Owner email lookup: resolving a HubSpot owner by email address costs an additional lookup against HubSpot. Supplying the owner id performs better than searching by email, which is why the shipped owner-email mapping prefers the value already on the company and only falls back to a lookup when it is empty.
Duplicate associations of different types: the same pair of records can be linked more than once in HubSpot under different association tags. Each such tag transfers as its own iPaaS.com relationship.
A child company can be associated with only one parent company in HubSpot, though a parent company can have many child companies.
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

Unique company names: because iPaaS.com requires company names to be unique, keep names unique on the HubSpot side so a transfer resolves to the intended iPaaS.com record.
Category assignments are replaced, not merged: when category assignments are written to an iPaaS.com company, any assignment not included in the request is removed. If the iPaaS.com company carries several assignments and a transfer from HubSpot includes only one, only that one remains afterward. Remove the mapping to the Categories field to disable this behavior. The Add/Update HubSpot Customer Category TO iPaaS.com collection may also be disabled to prevent category transfer entirely.
Primary billing is asserted every time: the address mapping sets the primary-billing flag on each transfer, so the imported address is always presented to iPaaS.com as the company's primary billing address. This matches the way the opposite-direction Company collections read the address back out of iPaaS.com, so an address that round-trips returns to the same place on the HubSpot company.
Address duplicate protection comes from external ID linking: repeat transfers of the same company resolve to the same iPaaS.com address through the external-id link, so the address is updated rather than duplicated. This collection does not additionally compare address values to skip a transfer.
A single-word company name produces the same first and last name: because the recipient name on the address is derived by splitting the company name on spaces, a company named with one word supplies that same word as both FirstName and LastName.
Relationships require a unique type and related-to-id combination: this is the constraint that the appended association tag on the related-to-id exists to satisfy. Removing the append causes duplicate errors as soon as a company carries more than one association to the same record.
The related record must exist in iPaaS.com first: the association filter skips any association whose other end has not transferred. Ordering the transfer so that contacts and companies arrive before their associations avoids relationships being silently left behind.

Setup Requirements

HubSpot Configuration

Confirm the connected HubSpot account can read companies and their contact and company associations.
Create the company category property named in Company Category Field Name as a Dropdown select property on the Company object, with at least one option defined, if company categories should transfer.

iPaaS.com Configuration

Configure a company polling schedule in the iPaaS.com event system using the Webhook (poll request) event type. No transfers occur on a schedule until polling is configured.
Create the HubSpot Owner Id and HubSpot Owner Email custom fields on the iPaaS.com Company module so the shipped owner mappings have a destination.
Populate the Company Category Field Name subscription setting if company categories should transfer, or leave it empty to disable category processing.
Plan the DestinationValue preservation mappings described under Unmapped Field Overwrite Risk before enabling a bi-directional transfer.

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

Integration Flow

A scheduled company poll, or a poll request sent manually, asks HubSpot for the companies modified since the timestamp saved on the subscription by the previous poll.
Each returned HubSpot company is retrieved with its mapped properties, including any custom properties resolved by their HubSpot property label.
The company's contact and company associations are retrieved with it, so the relationships travel with the record rather than as a separate lookup.
When the Company Category Field Name setting is populated, the company's category value is read from the named HubSpot property and resolved into an iPaaS.com customer category. A category is linked by name where a matching iPaaS.com category exists, and transferred as a dependent record where it does not.
The records the company depends on are resolved so they do not have to be transferred first. If the HubSpot company is not already linked, the integration looks for an existing iPaaS.com Company with the same name and links to it rather than creating a second record. For each association, the record at the other end is transferred first — a contact as an iPaaS.com Customer, a company as an iPaaS.com Company — so the relationship has something to point at.
The assembled company is dispatched to iPaaS.com, where it is created if it is not yet linked and updated in place if it is. The HubSpot company id is recorded as the external-id link.
The child collections add the company's address and its relationships as part of the same transfer. Each association is checked against the association collection's mapping filter first, and one whose related record has not yet reached iPaaS.com is skipped.
Because the iPaaS.com write replaces the record, only the values the collections map are present afterward. Any iPaaS.com field left unmapped is cleared.

If a prerequisite transfer fails, the company transfer fails with it, so the Customer, Company Category, and Company Relationship mappings must be configured correctly for company transfers to succeed.

Mappings

Add/Update HubSpot Company TO iPaaS.com (Parent)

iPaaS.com data type: Customer Company

This collection brings the HubSpot company into iPaaS.com, creating the iPaaS.com Company when it does not yet exist and updating it when it does, and it is the parent under which the address and association children run.

Mapping Type	Source Field (HubSpot)	Destination Field (iPaaS.com)	Description
Field	Domain	Url	Optional. The HubSpot company domain, written to the iPaaS.com Company website address. HubSpot treats the domain as a company's primary identifier, so carrying it into iPaaS.com keeps the two records recognisable as the same business even though iPaaS.com does not require the value.
Field	Name	Name	Required. The HubSpot company name, written to the iPaaS.com Company Name. The iPaaS.com Company API requires a name, and requires the combination of name and department to be unique when a company is created — since department is not mapped here, this behaves as a uniqueness requirement on the name alone. A company with no name, or with a name already used by another iPaaS.com company, is rejected. The name is also what the integration matches on when a HubSpot company is not yet linked: an existing iPaaS.com Company with the same name is linked rather than duplicated. Keep HubSpot company names accurate so that match resolves to the intended record.
Field	Phone	PhoneNumber	Optional. The HubSpot company phone number, written to the iPaaS.com Company phone number.
Field	HubSpotOwnerId	HubSpot Owner Id	Optional. Stores the HubSpot owner id on the iPaaS.com Company custom field named HubSpot Owner Id. Create that custom field on the iPaaS.com Company module for this mapping to have somewhere to write. Storing the owner id matters for bi-directional sync: HubSpot owns this value, iPaaS.com has no equivalent field of its own, and keeping it on the iPaaS.com record is what allows the owner to be re-applied when the company transfers back to HubSpot.
Field	Description	Description	Optional. The HubSpot company description, written to the iPaaS.com Company description.
Dynamic Formula	`return await ConvertHubSpotCategoryToiPaaS(CompanyCategories);`	Categories	Optional. Converts the company's HubSpot category into the matching iPaaS.com category assignment, resolving each category to its iPaaS.com id.
Dynamic Formula	`if(HubSpotOwnerEmail == null \|\| HubSpotOwnerEmail == "") return await GetOwnerEmailById(HubSpotOwnerId); return HubSpotOwnerEmail;`	HubSpot Owner Email	Optional. Stores the company owner's email address on the iPaaS.com Company custom field named HubSpot Owner Email, alongside the owner id mapping in this table. Create that custom field on the iPaaS.com Company module for this mapping to have somewhere to write. The formula prefers the owner email already present on the HubSpot company and uses it as-is. Only when that value is empty does it look the owner up by the owner id and return the resulting email address. This ordering avoids an extra lookup against HubSpot on every transfer, which is the slower path.
Dynamic Formula	`return await GetSpaceportIdAsync(HsParentCompanyId, "Company", SpaceportSystemId);`	ParentCompanyId	Optional. Takes the HubSpot parent company id, resolves it to the iPaaS.com Company linked to that HubSpot company, and sets it as the parent on the iPaaS.com Company. The value is empty when the HubSpot company has no parent, or when the parent company has not yet been transferred to iPaaS.com and therefore has no link to resolve. In that case the parent is simply not set; transferring the parent company first establishes the link and a later transfer of the child populates it.

Add/Update HubSpot Company Address TO iPaaS.com (Child)

iPaaS.com data type: Customer Company Address

This collection imports the single address held on the parent HubSpot company into iPaaS.com as the company's primary billing address, deriving the address's recipient name from the parent company's name because a HubSpot company carries no person name.

Two control flags shape how the address is written, and both are set deliberately by the template. IsPrimaryBilling is set so the imported address lands as the company's primary billing address in iPaaS.com, which matches the way the opposite-direction Company collections read the address back out of iPaaS.com, so an address that round-trips returns to the same place on the HubSpot company. PreventDuplicate is set so iPaaS.com does not transfer the address when all of the requested address values already exist as an iPaaS.com address on that company, which keeps repeated company transfers from stacking up duplicate address records. These are control flags, not address data; they are listed with the address fields below but do not themselves write a value onto the address.

Mapping Type	Source Field (HubSpot)	Destination Field (iPaaS.com)	Description
Dynamic Formula	`Parent.Address`	Address1	Recommended. Reads the street address held on the parent HubSpot company and writes it to the iPaaS.com Company Address Address1. The iPaaS.com Company Address API does not require any individual address field, but an address without a street line is not usable downstream. A standard HubSpot company holds a single address, so this is the only street value available to import. Subscribers or their MiSP can re-source this mapping if the company's address fields are not where their business keeps the address.
Dynamic Formula	`Parent.Address2`	Address2	Optional. Reads the second street address line held on the parent HubSpot company and writes it to the iPaaS.com Company Address Address2. The iPaaS.com Company Address API does not require it. If the HubSpot company has no value in this field, no value transfers.
Dynamic Formula	`!string.IsNullOrEmpty(Parent.Name) ? Parent.Name.Split(" ").FirstOrDefault() : null;`	FirstName	Optional. The iPaaS.com Company Address API does not require a recipient name. A HubSpot company record has no first or last name property, so the template derives a recipient from the company Name: it splits the name on spaces and writes the leading word to the iPaaS.com address FirstName. If the company has no name, no value transfers. Note that a company named with a single word supplies that same word to both FirstName and LastName. Subscribers or their MiSP who maintain a genuine contact name for the company's address can re-source this mapping to a HubSpot property that holds it.
Dynamic Formula	`Parent.City`	City	Recommended. Reads the city held on the parent HubSpot company and writes it to the iPaaS.com Company Address City. The iPaaS.com Company Address API does not require it, but it is needed for a usable address record. HubSpot does not validate or standardize this value, so it transfers exactly as entered.
Dynamic Formula	`Parent.Country`	Country	Recommended. Reads the country held on the parent HubSpot company and writes it to the iPaaS.com Company Address Country. The iPaaS.com Company Address API does not require it, but it is needed for a usable address record. HubSpot does not standardize country values, so they transfer exactly as entered.
Dynamic Formula	`Parent.Zip`	PostalCode	Recommended. Reads the Zip value held on the parent HubSpot company and writes it to the iPaaS.com Company Address PostalCode, which is the equivalent iPaaS.com field. The iPaaS.com Company Address API does not require it, but it is needed for a usable address record.
Dynamic Formula	`Parent.Name`	Company	Recommended. Writes the parent HubSpot company's full Name to the iPaaS.com Company Address Company field. Unlike the FirstName and LastName mappings, this mapping is not split on spaces, so the complete company name is preserved here. This is the address's own free-text company line and is not a structured link to a company record; the relationship between the company and other records is handled by the Add/Update HubSpot Company Association TO iPaaS.com collection.
Dynamic Formula	`Parent.Phone`	PhoneNumber	Optional. Reads the phone number held on the parent HubSpot company and carries it onto the iPaaS.com Company Address PhoneNumber. The iPaaS.com Company Address API does not require it. This is the phone number stored on the address itself, which is separate from the phone number stored on the company record.
Dynamic Formula	`true`	IsPrimaryBilling	Recommended. A control flag rather than a data field, set deliberately by the template. Because a standard HubSpot company holds only one address, the template targets the company's primary billing address in iPaaS.com so that there is a single, predictable place for it to land. The opposite-direction Company collections read the primary billing address back out of iPaaS.com when writing to HubSpot, so an address that round-trips returns to the same fields on the HubSpot company. Changing this mapping breaks that round trip and is not advised unless subscribers or their MiSP are deliberately redesigning where company addresses are held in iPaaS.com.
Dynamic Formula	`Parent.State`	Region	Recommended. Reads the State value held on the parent HubSpot company and writes it to the iPaaS.com Company Address Region, which is the equivalent iPaaS.com field. The iPaaS.com Company Address API does not require it, but it is needed for a usable address record. HubSpot does not standardize state values against any list, so whatever text is on the company transfers unchanged. Subscribers or their MiSP whose business requires a consistent state format should ensure the values are entered consistently in HubSpot.
Dynamic Formula	`!string.IsNullOrEmpty(Parent.Name) ? Parent.Name.Split(" ").LastOrDefault() : " ";`	LastName	Optional. The companion to the FirstName mapping in this table. It splits the parent HubSpot company Name on spaces and writes the trailing word to the iPaaS.com address LastName. Where the company has no name at all, a single space is written rather than no value, so the address always carries a last name. As with FirstName, a one-word company name means the same word is written to both fields. Subscribers or their MiSP can re-source this mapping to a HubSpot property holding a real contact surname.
Static	`true`	PreventDuplicate	A control flag, set deliberately by the template. It tells iPaaS.com not to transfer the address when all of the requested address values already exist as an iPaaS.com address on that company. Because a HubSpot company address transfers every time the company does, this flag is what stops repeated company transfers from stacking up duplicate address records. It is not a data field and it does not appear on the finished address. When an address is skipped for this reason, nothing is written and no error is raised. Recommended: leave this set.

Add/Update HubSpot Company Association TO iPaaS.com (Child)

iPaaS.com data type: Company Relationship

This collection imports the parent HubSpot company's contact and company associations into iPaaS.com as Company Relationships, so a link created by a HubSpot user becomes visible to every other system connected through iPaaS.com.

Mapping Filter

var customerId = await GetSpaceportIdAsync(Id.Split("|")[0], "Customer", SpaceportSystemId);
if(customerId == null || customerId <= 0){
 customerId = await GetSpaceportIdAsync(Id.Split("|")[0], "Company", SpaceportSystemId);
 if(customerId == null || customerId <= 0)
    return false;
}
return true;

Filter Description. The filter decides whether an association is worth bringing into iPaaS.com, and it lets through only associations whose other end already exists there. It takes the first segment of the association's id — the HubSpot id of the record at the other end, before any appended association tag — and looks for an iPaaS.com Customer linked to that HubSpot id. If a linked customer is found, the association passes. If no linked customer is found, the filter looks for an iPaaS.com Company linked to the same HubSpot id instead, and the association passes if one is found. If neither lookup resolves, the association does not pass and is skipped.

In subscriber terms, an association is skipped when the record it points at has not been transferred to iPaaS.com yet. This is not an error: nothing is written, and no entry appears under Dashboard, Integration Monitoring, Error Logs, because there is no iPaaS.com record for the relationship to point at. Once the contact or company at the other end has itself transferred, a subsequent transfer of the owning company brings the relationship across.

Mapping Type	Source Field (HubSpot)	Destination Field (iPaaS.com)	Description
Dynamic Formula	`if(RelationshipType == "child_to_parent_company"){ return "Parent Company"; } return char. ToUpper(ReadOnlyRelationshipType[0]) + ReadOnlyRelationshipType.Substring(1);`	Type	Recommended. Sets the iPaaS.com relationship type from the HubSpot association. The iPaaS.com Company Relationship API does not require a type, but a relationship without one carries no meaning about how the two records are linked. The formula handles HubSpot's parent-company association as a special case: where the association is HubSpot's child-to-parent-company link, it returns the type Parent Company. For every other association it returns HubSpot's own association type with its first letter capitalized, so that HubSpot's wording is preserved in a presentable form. Because the type is taken from HubSpot rather than from a fixed list, an association tag defined in a HubSpot portal transfers under its own name without any mapping change. It is not advised to alter this mapping, as it is required to support the HubSpot associations.
Field	RelationshipType	Company Relationship Type	Optional. Writes the raw association type label, exactly as HubSpot supplies it, to an iPaaS.com Relationship custom field. It is included as a worked example of capturing association information that has no standard iPaaS.com field of its own. Its value is keeping HubSpot's own wording available for later use. The Type mapping reshapes the association type for iPaaS.com — renaming the parent-company link and capitalizing the rest — whereas this mapping preserves the original, so any mapping logic that needs to distinguish HubSpot association tags precisely can read it here. Custom fields are supported as destinations in this direction only; adding further Relationship custom-field mappings is the supported way to capture more information about an association.
Dynamic Formula	`var customerId = await GetSpaceportIdAsync(Id.Split("\|")[0], "Customer", SpaceportSystemId); if(customerId != null){ return customerId + "\|" + RelationshipType; } else{ var companyId = await GetSpaceportIdAsync(Id.Split("\|")[0], "Company", SpaceportSystemId); if(companyId != null) return companyId + "\|" + RelationshipType; }`	RelatedToId	Required. The iPaaS.com Company Relationship API requires a related-to-id on every relationship, and this mapping supplies it.
Dynamic Formula	`CompanyName != null ? CompanyName : CustomerFirstname`	Name	Optional. Writes a readable label for the association to an iPaaS.com Relationship custom field. The fields available on a relationship depend on the record at the other end: an association to a company offers CompanyName and CompanyDomain, while an association to a contact offers CustomerFirstName, CustomerLastName, and CustomerEmail. This mapping uses the associated company's name where one is present, and otherwise falls back to the associated contact's first name — so a single mapping produces a label for either kind of association. This is a worked example of the pattern described on the Company Relationship Type mapping: subscribers or their MiSP can add further mappings to iPaaS.com Relationship custom fields to capture more of the association's detail. If the label is not needed, this mapping can be removed without affecting the association itself.

RelatedToId

Required. The iPaaS.com Company Relationship API requires a related-to-id on every relationship, and this mapping supplies it. The formula takes the HubSpot id of the record at the other end of the association and looks for a linked iPaaS.com Customer carrying that id; if none is found, it looks for a linked iPaaS.com Company instead. The resolved iPaaS.com id is what the relationship points at.

The formula then appends the HubSpot association type to that id, separated by a pipe character. This is deliberate and is required for correctness. iPaaS.com requires a unique relationship-type and related-to-id combination and rejects duplicates, but a single iPaaS.com relationship can produce more than one HubSpot association when the company is created in HubSpot. Without the appended tag, those extra associations would return to iPaaS.com under the same related-to-id and be rejected as duplicates. With it, each association tag transfers as its own iPaaS.com relationship.

Two consequences are worth planning for. Other integrations consuming this relationship data must account for the resulting id format when they read iPaaS.com company relationships. And where additional association types should not transfer at all, subscribers or their MiSP can prevent them with a mapping collection filter rather than by changing this mapping. It is not advised to alter this mapping otherwise, as it is required to support the HubSpot associations. Consult your MiSP for assistance.

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 inbound company transfers are:

HubSpot API Communication: covers the messages raised when HubSpot rejects or cannot return a company read, 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.
Duplicate company name: iPaaS.com rejects a company whose name duplicates an existing company, because the company name and department combination must be unique and department is not mapped. The transfer fails rather than merging. Resolve the collision by making the HubSpot company name unique, or by linking the HubSpot company to the existing iPaaS.com record, then re-sync.
Company category property errors: raised when the property named in Company Category Field Name does not exist in HubSpot, or is not a Dropdown select property with at least one option. Correct the property in HubSpot, or clear the setting to disable category processing, then re-sync the company.
Prerequisite failures: a company transfer fails when one of the records it depends on — a Customer, a Company Category, or a Company Relationship — cannot be transferred. The reported error concerns the dependent record; correcting that record's mappings and re-syncing the company resolves it.

Errors are reported under Dashboard, Integration Monitoring, Error Logs. An association skipped by the mapping filter is not an error and produces no entry there.

Testing & Validation

Test Scenarios

Create a new HubSpot company that has never been transferred, then manually sync it by its HubSpot company id. Confirm a new iPaaS.com Company is created and that it carries the HubSpot company id as its external-id link.
Change the name or domain on that same HubSpot company and re-sync. Confirm the existing iPaaS.com Company is updated in place and no second company appears.
Create an iPaaS.com Company with the same name as an unlinked HubSpot company, then sync that HubSpot company. Confirm the integration links to the existing iPaaS.com Company by name rather than creating a duplicate.
Populate the address fields on the HubSpot company and re-sync. Confirm an iPaaS.com Company Address is created, that it is flagged as the primary billing address, and that its recipient name is derived from the company name. Repeat with a single-word company name and confirm the same word appears as both first and last name.
Set an email address on an iPaaS.com Company, then re-sync the company from HubSpot without a preservation mapping. Confirm the email address is cleared. Add a DestinationValue mapping for Email Address, re-sync, and confirm the value is retained.
Associate the HubSpot company with a contact that has not been transferred to iPaaS.com, then sync. Confirm the association is skipped, that no iPaaS.com Company Relationship is created, and that no error is raised. Transfer the contact, re-sync the company, and confirm the relationship now appears.
Add two association tags between the same pair of HubSpot records and sync. Confirm both transfer as separate iPaaS.com Company Relationships rather than colliding as duplicates.
Populate the Company Category Field Name setting with a valid HubSpot Dropdown select property, assign a category to the HubSpot company, and re-sync. Confirm the category assignment reaches the iPaaS.com Company. Clear the setting and confirm category processing stops with no error raised.
Add a custom property to the HubSpot company, map it by its property label to an iPaaS.com Company custom field, and re-sync. Confirm the value reaches the custom field.

Validation Checklist

A first transfer creates an iPaaS.com Company and records the external-id link.
A second transfer of the same company updates it rather than creating a duplicate.
An unlinked HubSpot company whose name matches an existing iPaaS.com Company links to it instead of duplicating it.
Fields left unmapped on the iPaaS.com Company, Company Address, and Company Relationship are cleared on update unless a DestinationValue mapping preserves them.
The imported address is flagged as the company's primary billing address.
Associations appear only once the record at the other end exists in iPaaS.com, and a skipped association raises no error.
Custom field values reach the iPaaS.com Company custom fields named in the mappings.
Errors appear under Dashboard, Integration Monitoring, Error Logs.

Additional Notes

Company merges: merging two companies is a manual action in HubSpot. The integration does not merge iPaaS.com companies, and it does not detect that a merge occurred.
Multiple addresses per company are out of scope, because a standard HubSpot company holds only one address.
Address validation or standardization is out of scope; neither system normalizes the address during transfer.
Associations to objects other than contacts and companies are out of scope; only the company's contact and company associations are imported.
Association start and end dates are out of scope, because HubSpot associations do not carry them.
At the time this documentation was written, the HubSpot association tag is appended to the related-to-id to satisfy the iPaaS.com uniqueness requirement, so other integrations consuming iPaaS.com company relationship data must account for that id format. Where additional association types should not transfer at all, subscribers or their MiSP can prevent them with a mapping collection filter rather than by changing the mapping.
At the time this documentation was written, category functionality is best suited to a single category assignment per company, because HubSpot holds one property for the category designation.
At the time this documentation was written, HubSpot custom properties are not supported as source fields on the HubSpot Company Address or the HubSpot Company Association.
At the time this documentation was written, a company deletion in HubSpot does not transfer to iPaaS.com in any form.

HubSpot to iPaaS.com Company Mapping Documentation