HubSpot + NetSuite integration

NetSuite is usually the only place a company’s numbers are true, and a NetSuite licence costs enough that most sellers do not have one. So the people talking to an account cannot see what that account has already bought. They ask operations, operations exports a spreadsheet, and by the time it lands the renewal conversation has happened without it.

The request that reaches us is almost always narrower than “integrate NetSuite”. Show open orders on the company record. Flag accounts that are past due before a rep books a meeting. Stop sellers creating a customer finance has to merge next quarter. Each is a different object moving in a different direction, which is why the scoping conversation decides more here than the build.

A second pressure shapes the design. Finance teams running NetSuite have spent years cleaning their customer master, and they are right to be wary of a sales tool writing into it. So almost everything moves one way, into HubSpot, and only the fields a closed deal legitimately owns move back. That asymmetry is a decision about who owns the record rather than a limit of the API, and settling it early is what stops the rebuild.

Six objects carry most of the value. The customer becomes a HubSpot company, the contact becomes a HubSpot contact, the sales order becomes a deal, and invoices, item fulfilments and items land beside them as custom objects and products. We leave everything else out of a first build.

Every one of those rows keys on the NetSuite internal id, held in a custom HubSpot property, and never on a name. Entity ids and customer names both change when finance reorganizes the master. The internal id does not, which makes it the only key that survives. Contacts are the exception: email is the practical match key there, with the contact internal id as the tie breaker when two people share an address.

Getting the direction of each object wrong is expensive to unwind later. NetSuite owns the customer, the order and the invoice, so those move into the portal and stay read only there. HubSpot owns the pipeline, the deal owner and the activity history. The single write back worth building on a first pass is a closed won deal creating or updating a customer, and even that is worth holding behind a review queue for the first month.

The runtime is a polling watermark sync, because SuiteTalk REST offers no event subscription to hook into. A service holds an OAuth 2.0 client, reads each record type on a schedule with a filter on the last modified date, and keeps a checkpoint per record type so a restart resumes instead of reloading.

Writes into HubSpot go through batch upserts keyed on the internal id in a custom property, and a separate pass then associates the order to the company and the invoice to the order. Splitting those two steps is what makes a replay safe. Running the same batch twice changes nothing, and running the association pass twice changes nothing either.

State lives in the service, not in either platform. A replay endpoint takes a record type and a time range and re-reads it. A reconciliation endpoint counts NetSuite records against HubSpot records for the same window and reports the difference rather than quietly correcting it. When counts disagree, a person looks.

What decides the route here is how far past the customer record you need to go. HubSpot’s own NetSuite app keeps account and contact records in agreement, and for a team that wants nothing more it is the right answer and costs nothing to try. It syncs fields, so it does not carry a sales order, an item fulfilment or an invoice, and no amount of configuration will make it.

Once transactions are in scope the choice narrows to a service we build or a general purpose automation platform. That platform bills per task, so the cost tracks order volume rather than the value of the work, and it draws on the same account level concurrency budget as every other NetSuite integration. A dedicated service costs more to stand up and behaves predictably after that.

1. Scope. Discovery covers the object list, the direction of each object and the key. Most of it goes on the customer master and who may change it.
2. Architect. We fix the key, the watermark, the batch size and the association order, then write them down so the build has nothing left to invent.
3. Build. The service is written against a sandbox account, with the account and portal allowlist in place from the first commit.
4. Validate. We run a full reload into a HubSpot sandbox, reconcile counts by record type, and walk the differences with the person who owns the ledger.
5. Operate. Cutover is a token swap. After that we watch the run history, keep the replay and reconciliation endpoints available, and adjust the mapping as NetSuite changes.