This article documents the known limitations and important behaviors of the iPaaS.com HubSpot integration, so subscribers or their MiSP know what to expect and how to work around each one. Every limitation below is stated as it stands at the time this documentation was written; HubSpot's platform and this integration both change over time, so re-check this article after an update.

Each limitation gives a technical description and a plain-language What this means for you.

Areas covered: Cross-cutting behavior · Customers and companies · Categories · Addresses · Relationships · Products · Transactions and line items · Placeholder values to replace before go-live · Platform scope.

At the time this documentation was written, deleted-record transfer is not supported for any HubSpot mapping collection, in either direction. Deleting a contact, company, product, order, line item, address, relationship, or category value in one system leaves the linked record in the other system untouched. This applies to every collection in the template without exception.

What this means for you: removing a record is a manual action in both systems, performed under a supervised process. Plan for deletions to be handled by hand on each side, and do not rely on a deletion in one system to clear data in the other. If a record must be retired rather than removed, consider marking it inactive through a mapped field instead.

At the time this documentation was written, initialization is not supported for HubSpot in iPaaS.com. No data type can be transferred in bulk through initialization, and all data synchronization must be configured through the mapping collections.

What this means for you: there is no one-click bulk backfill for any entity. Seed existing data using the Manual Sync page, or by scheduling the polling events described in the individual mapping collection descriptions, and expect an initial load to run through normal transfer processing.

At the time this documentation was written, the iPaaS.com API replaces the whole record on update. On the seven collections that transfer TO iPaaS.com, any iPaaS.com field that the collection does not map is therefore cleared each time HubSpot updates an existing iPaaS.com record. The clearest example: HubSpot has no company email property by default, so there is no HubSpot value to send, and an email address held on the iPaaS.com Company is removed when that company is updated from HubSpot.

The fields left unmapped by the default template on each inbound collection are:

A HubSpot association carries no start date, end date, or primary flag, and a standard HubSpot address has no equivalent for a third street line, an address type, or an address name — so none of those fields has a HubSpot source to supply it.

This does not apply in the opposite direction. On the twelve collections that transfer FROM iPaaS.com, an update sends only the values it has, so a HubSpot property with no mapping keeps whatever it already held and is not blanked.

What this means for you: when running a bi-directional sync, map every value you wish to preserve. For each field above that is maintained in iPaaS.com, add a mapping on the inbound collection 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 Email Address field on Add/Update HubSpot Company TO iPaaS.com. Subscribers or their MiSP should plan these mappings before enabling a bi-directional transfer.

At the time this documentation was written, HubSpot limits any single search query to 10,000 total results and rejects a request to read beyond that point. A polling window that matches more than 10,000 changed records therefore fails at the 10,000-record boundary rather than transferring a partial set, and the failure is reported in the error logs.

What this means for you: this affects large tenants and initial loads most. Keep each polling window small enough that no single poll matches more than 10,000 records — poll frequently rather than sweeping a long date range in one pass. When seeding a large existing HubSpot data set, break the load into several narrower passes and reconcile the record counts in both systems afterward. If a poll over a wide window fails under Dashboard > Integration Monitoring > Error Logs, narrow the window and re-run it. Subscribers or their MiSP should validate the record counts in a staging environment before a full production load.

At the time this documentation was written, HubSpot contacts, companies, and category values are not transferred to iPaaS.com 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 requests only the records modified since that timestamp. No inbound transfers occur at all until a polling schedule is configured.

What this means for you: configure a scheduled polling event for each inbound entity you intend to use, in the iPaaS.com event system, using the Webhook (poll request) event type. Choose a polling frequency that matches how quickly HubSpot changes need to reach iPaaS.com, and expect inbound changes to arrive on that cadence rather than in real time. A poll request may also be sent manually from the Manual Sync page.

At the time this documentation was written, the integration does not retry or back off when HubSpot rate-limits a request. A request rejected for exceeding HubSpot's limits fails the transfer it belongs to, and the failure is reported in the error logs rather than being retried automatically.

What this means for you: the throttling and concurrency settings on the subscription are the control that keeps request volume within HubSpot's limits. If rate limit errors appear under Dashboard > Integration Monitoring > Error Logs, reduce those values, and re-run the affected transfers from the Manual Sync page once the values are settled. Subscribers or their MiSP should avoid running several large transfers concurrently.

At the time this documentation was written, testing the connection in iPaaS.com reports success without confirming that HubSpot has accepted the stored credentials, so a successful test alone does not prove the connection works.

What this means for you: confirm the connection by running an actual transfer of a small record set and reviewing the outcome under Dashboard > Integration Monitoring > Error Logs. Credential and permission problems surface there on the first real transfer.

At the time this documentation was written, custom fields are not supported on the HubSpot side of the Customer Address, Company Address, Customer Relationship, Company Relationship, and Customer Category collections. A HubSpot custom property cannot be read from, or written to, any of those objects. Custom fields are supported on the Customer, Company, Product, Transaction, and Transaction Line Item collections.

One exception is worth knowing: on the two relationship collections that transfer TO iPaaS.com, iPaaS.com Relationship custom fields remain valid destinations, and the template already uses them — Company Relationship Type and Name are shipped examples. Subscribers or their MiSP may add further mappings to iPaaS.com Relationship custom fields to capture more information about a relationship. This applies to the TO iPaaS.com direction only.

What this means for you: if you need to carry extra detail on an address, a relationship, or a category, hold it on the parent Customer or Company record instead, where custom fields are supported. For inbound relationships, capture the additional detail on an iPaaS.com Relationship custom field.

At the time this documentation was written, record matching is implemented on the inbound direction only. A company, transaction, or product transferred FROM iPaaS.com that has no HubSpot record linked to it is created, not matched — even when a record with the same name, domain, order details, or SKU already exists in HubSpot. For companies, matching by name is available only when transferring TO iPaaS.com. For products, an existing unlinked HubSpot product with a matching SKU is not detected. The same link governs updates: the Update collections depend on the external-id link saved when the record was created or first matched, and a record with no link is created as new by its Add collection rather than updated.

What this means for you: link pre-existing HubSpot records before the first outbound transfer — the most reliable way is to transfer them into iPaaS.com first, which establishes the link — or expect to merge duplicates in HubSpot afterward. Subscribers or their MiSP should run a small pilot batch and inspect HubSpot for duplicates before a full outbound load.

At the time this documentation was written, when a customer transfer finds an existing record with the same email address, the two records are linked automatically and the transfer proceeds as an update instead of a create. That match links the customer only. The customer's addresses and other child objects are not linked by it, and may encounter transfer errors depending on the type of data conflict occurring. This applies in both directions.

What this means for you: after an email match links a customer for the first time, check the error logs for address or relationship failures on that record, and reconcile any conflicting child data by hand. Subscribers or their MiSP should validate this on a small record set before relying on email matching at volume.

At the time this documentation was written, no duplicate check is performed during a company transfer in either direction. HubSpot does not deduplicate companies created through its API, and iPaaS.com rejects a company whose name duplicates an existing one — so a name collision surfaces as a transfer failure rather than a merge. 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.

What this means for you: keep company names distinct in iPaaS.com, and expect a failure in the error logs rather than a silent merge when a duplicate name arrives. If you merge companies in HubSpot, reconcile the corresponding iPaaS.com records and their external-id links by hand.

At the time this documentation was written, only one HubSpot property holds the category designation for each record type, so only one of the iPaaS.com category assignments on a customer or company is reflected in HubSpot. When several assignments are provided, the last one processed becomes the final value of the HubSpot property and the others are not represented. This feature is best suited to a single category assignment per customer or company.

Category processing is also governed by the Contact Category Field Name and Company Category Field Name subscription settings, which name the HubSpot property by its label. Leaving either setting empty fully disables category processing for that record type — including the pre-processing that transfers dependent categories — and no error is raised to say so.

What this means for you: design around a single category per customer and per company. Subscribers or their MiSP who need several designations per record should hold the additional ones in separate HubSpot properties populated through custom field mappings on the Customer or Company collections. If categories are not appearing at all, confirm the relevant Category Field Name setting is populated with the HubSpot property's label.

At the time this documentation was written, adding a value to the HubSpot category property is a read-then-write operation: the integration reads the property's full list of values, appends the new one, and writes the whole list back. It does not check whether the list changed in between. Two category transfers running at the same time can therefore result in one of the new values being lost, and a value added directly in HubSpot between the read and the write can be dropped.

What this means for you: avoid running category transfers concurrently, and avoid editing the category property in HubSpot while a category transfer is in progress. Where values appear to be missing, re-running the transfer restores them. Subscribers or their MiSP should schedule category polls so they cannot overlap.

At the time this documentation was written, a HubSpot dropdown property is a flat list of values, so no parent or child relationship between categories is transferred in either direction. The HubSpot property itself is also not created by the integration.

What this means for you: maintain category hierarchy on the iPaaS.com side; HubSpot will hold a flat list of category names. Create the category property in HubSpot manually before the first transfer, as a Dropdown select field type on the Contact or Company object, with at least one value defined.

At the time this documentation was written, standard HubSpot contact and company fields hold a single address entry, so only one iPaaS.com address per contact and per company can be maintained through the integration. Inbound, that single HubSpot address becomes the record's primary billing address in iPaaS.com. Outbound, only the primary billing address is written. A HubSpot order holds one address of each kind, so only the primary billing address and the primary shipping address transfer with an order. Because a HubSpot company record carries no name properties for an individual, the recipient name on an imported company address is derived from the HubSpot company name rather than from a person.

What this means for you: keep the address you intend to synchronize flagged as the primary billing address in iPaaS.com — additional addresses stay in iPaaS.com and are not represented in HubSpot. Expect a company address to arrive in iPaaS.com carrying the company name as its recipient name.

At the time this documentation was written, neither system normalizes or standardizes an address during transfer — a state, region, or postal code transfers exactly as it was entered. The inbound address collections also ship with a duplicate-prevention flag set deliberately, so an address whose values exactly match an existing iPaaS.com address is skipped rather than transferred again. That skip is not an error, so nothing appears in the error logs to explain why an address was not transferred.

What this means for you: standardize address values at the point of entry — the integration will not correct them. If an address appears not to have transferred and no error is logged, check whether an identical address already exists on the iPaaS.com record; that is the expected behavior and it is what prevents repeated transfers from creating duplicate addresses.

At the time this documentation was written, only relationships between contacts and companies are transferred; associations to any other HubSpot object are not. Only basic template HubSpot associations can be uploaded from iPaaS.com — creating a new custom HubSpot association label from iPaaS.com is not supported. Where an association originated in HubSpot and was transferred to iPaaS.com, its original association type is preserved when it transfers back.

What this means for you: create any custom association label in HubSpot first, then let it round-trip; a label invented on the iPaaS.com side will not appear in HubSpot. Relationships to objects other than contacts and companies must be maintained in HubSpot by hand.

At the time this documentation was written, a relationship is skipped by its mapping filter when the record it points at has not yet transferred to the other system, or when its related-to id is empty. The relationship is skipped rather than failed, so no error is raised and no entry appears in the error logs to explain why the association is missing. This applies in both directions.

What this means for you: transfer the related contacts and companies before their relationships, and re-run the relationship transfer once both records exist and are linked. If an association is missing and the logs are silent, confirm both ends of it have transferred.

At the time this documentation was written, the HubSpot association type is appended to the related-to id on inbound relationships, in order to satisfy the iPaaS.com uniqueness requirement so that multiple association tags on the same pair of records remain distinct.

What this means for you: this only matters if another integration reads iPaaS.com customer or company relationship data. That integration must account for the composite id format rather than expecting a bare record id.

At the time this documentation was written, a product price of zero is not written to HubSpot. A price of zero is treated as though no price had been supplied, so a genuinely free product transfers with no price set — and because an update sends only the values it has, a HubSpot product that already carries a price keeps the price it had rather than being reduced to zero. The same applies to the other numeric product properties, such as a quantity or an amount. A value that has been deliberately cleared — an empty name, an empty description, or an empty date — is likewise treated as no value at all, so the HubSpot property keeps its previous content rather than being blanked.

This affects the standard product properties only. A custom field carrying a zero or an empty value is written to HubSpot.

What this means for you: subscribers or their MiSP whose catalogue contains free or zero-priced items should set a nominal price in iPaaS.com, or set the price in HubSpot by hand, and should validate the result in a staging environment before a full catalogue load. Where a HubSpot product property must be emptied, empty it in HubSpot. Pay particular attention to a product whose price is reduced to zero after it has already transferred — the stale HubSpot price will remain.

At the time this documentation was written, this integration writes products to HubSpot but does not transfer HubSpot products back into iPaaS.com. iPaaS.com product variants, options, units, kits, and related products are not transferred as records in their own right — a variant participates only when a line item's SKU resolves to it, in which case the variant's parent product is transferred. Inventory quantities, costs, and stock levels are not transferred at all.

What this means for you: maintain the product catalogue in iPaaS.com as the source of truth; a product created in HubSpot stays in HubSpot. Manage inventory and costs outside this integration, and expect a HubSpot product to represent the parent product rather than an individual variant.

At the time this documentation was written, this integration does not transfer orders or line items inbound. An order created in HubSpot stays in HubSpot.

What this means for you: iPaaS.com is the source of truth for orders. If order data must originate in HubSpot, it has to be entered in iPaaS.com separately; there is no inbound order collection to enable.

At the time this documentation was written, the currency mapping on the Add collection sends the static value USD rather than reading a currency from the iPaaS.com Transaction. The Update collection does not map the currency at all, so an order created with the wrong currency keeps that currency in HubSpot unless it is changed there by hand.

What this means for you: before the first transfer, change the Currency Code mapping on Add HubSpot Order FROM iPaaS.com to the currency your orders are placed in. Getting this wrong is expensive to correct — every affected order must be fixed in HubSpot individually, because a later transfer will not repair it.

At the time this documentation was written, the Transfer Products as a Prerequisite for Transactions setting is recognised only when it is set to the value true. Values such as 1, yes, or on silently disable product prerequisites rather than reporting a configuration error. The customer and company prerequisites for a transaction are never governed by this setting; they always run.

What this means for you: set the value to the exact word true if you want a transaction to transfer its products ahead of itself. If products are unexpectedly missing from HubSpot when orders arrive, check this setting's value first — it is the most common cause, and it fails silently.

At the time this documentation was written, the line item collections have no prerequisite handling. A line whose product is not already in HubSpot, and whose parent transaction did not transfer that product, produces a line item with no product reference rather than reporting an error.

What this means for you: ensure products reach HubSpot before the orders that reference them — either by enabling Transfer Products as a Prerequisite for Transactions with the exact value true, or by transferring the catalogue first. A line item with no product reference will not raise an error, so check the HubSpot order lines after the first transfers.

At the time this documentation was written, the Update collection updates the line items it is given and does not remove HubSpot line items that no longer have a matching iPaaS.com transaction line. A line removed from an iPaaS.com Transaction stays on the HubSpot order.

What this means for you: where a line is removed from an order after it has transferred, remove the corresponding HubSpot line item by hand. Reconcile order totals in HubSpot after any order revision that removes a line.

At the time this documentation was written, the quantity, price, amount, discount, and tax mappings on the line item collections ship with formulas that send a value only when it is greater than zero. A line that legitimately carries a zero quantity or a zero price therefore reaches HubSpot with that field unset, and on an update the value already on the HubSpot line item is left as it is — so a line whose quantity or price falls to zero in iPaaS.com keeps its previous HubSpot value. This is the shipped formula's doing rather than a restriction of the integration.

What this means for you: subscribers or their MiSP who need a zero recorded in HubSpot can edit the formula on the affected mapping to return the value unconditionally. Make the same change in both Add HubSpot Order Line Item FROM iPaaS.com and Update HubSpot Order Line Item FROM iPaaS.com so that created and updated line items agree. The full editable formula is visible on the mapping itself in iPaaS.com.

At the time this documentation was written, an iPaaS.com Transaction can carry payments, taxes as separate records, tracking, and notes, and an iPaaS.com transaction line can carry line-level shipping addresses, gift card details, coupons, and line discounts as separate records — none of these are mapped to HubSpot by the template collections.

What this means for you: the HubSpot order represents the order's commercial summary, not its full financial detail. Keep iPaaS.com as the system of record for payment, tax, and fulfillment detail, and do not expect HubSpot reporting to reconcile against it at that level.

The template ships with three values that are examples or defaults rather than production settings. Review each one before the first live transfer.

At the time this documentation was written, the Interested Sports iPaaS.com custom field and the Favourite Sports HubSpot property are example fields from a demonstration environment. They exist to demonstrate custom-field mapping by HubSpot property label, and they round-trip between Add/Update HubSpot Contact TO iPaaS.com and Add/Update HubSpot Contact FROM iPaaS.com.

What this means for you: replace them with your own iPaaS.com custom field and the matching HubSpot property label. Keep the pattern — it is the worked example to copy when adding a label-based custom-property mapping of your own.

At the time this documentation was written, the Currency Code mapping on Add HubSpot Order FROM iPaaS.com ships with a fixed value of USD.

What this means for you: replace it with the currency your orders are placed in, before the first transaction transfers. See the currency limitation above for why this is hard to correct afterward.

At the time this documentation was written, Update HubSpot Company FROM iPaaS.com, Update HubSpot Company Association FROM iPaaS.com, Update HubSpot Order FROM iPaaS.com, and Update HubSpot Order Line Item FROM iPaaS.com each ship with the same field set as their corresponding Add collection. Every mapped field — including the lifecycle stage and the owner assignment — is therefore re-applied to the HubSpot record on every update. This is how the template is intended to ship: no field is treated as create-only out of the box, so that the shipped behavior is complete and predictable.

What this means for you: decide which fields should be set once at creation and then left alone in HubSpot. Subscribers or their MiSP should remove those mappings from the Update collection so a HubSpot-side change survives the next update. A lifecycle stage advanced by a HubSpot user, or an owner reassigned in HubSpot, is the most common thing subscribers want to protect this way. A change intended to apply to both creation and update must be made in both collections.

HubSpot does not publish numbered platform releases for the APIs this integration uses; it runs a single continuously updated production platform. There is therefore no platform version to pin the integration to, and no minimum version to configure.

What this means for you: because HubSpot changes without a version boundary, a limitation recorded here can be resolved or altered by HubSpot at any time. Subscribers or their MiSP should re-read this article after any significant change to the integration or to the HubSpot account, and validate behavior in a staging environment before relying on it in production.

This article documents 28 known limitations grouped into seven areas of the HubSpot integration, plus three placeholder values to replace before go-live.