HubSpot + ServiceNow integration

ServiceNow usually arrives through IT and then spreads. A company that runs its internal service desk on it often adds Customer Service Management, and from then on every customer case, entitlement and service contract lives on the same platform as the laptop requests. The sales and marketing teams work in HubSpot and see none of it.

The gap shows up at renewal and at escalation. An account manager books a renewal call without knowing the customer has three priority cases open. Marketing asks a customer for a case study the week an outage is escalated. Service leaders cannot see which accounts the pipeline depends on, so the customer behind the largest deal in flight waits in the same queue as everyone else.

ServiceNow is usually the most tightly governed system in the building. A platform team controls the instance, changes move on a release calendar, and nothing is installed casually. That shapes this integration more than the API does. The design reads what it needs from outside, asks for as little as possible inside the instance, and turns the one write back into ServiceNow into something the platform team can review before it lands. It also means the first scoping call includes the platform owner, not only the sales team.

Four tables carry the value. The Account table, customer_account, becomes the HubSpot company; ServiceNow describes it as the store for customer account and partner records, and it extends the core Company table. Contacts come from customer_contact, which extends the User table. Cases from sn_customerservice_case become HubSpot tickets in a pipeline of their own, and service contracts from ast_contract land on a custom object that a renewal pipeline can read. Teams that support customers through IT service management rather than Customer Service Management swap cases for the incident table, and the design stays the same.

Every row keys on the sys_id, the unique 32 character identifier ServiceNow gives each record, held in a custom HubSpot property. Case numbers are what people quote on the phone, so they travel as a readable property, but the key stays the sys_id. Contacts match on email first, with the sys_id breaking ties when two records share an address.

Direction follows ownership. ServiceNow owns the case and the contract, so both move one way. HubSpot owns the pursuit, so the only write back is a closed won deal creating the account, and it waits in a review queue until someone on the service side approves it.

This is a polling watermark sync, because ServiceNow documents no event subscription that an outside service can register. The service holds an OAuth client registered in the instance, using the client credentials grant ServiceNow documents for back-end integrations, and runs as a dedicated integration user.

On each run it asks the Table API for rows whose sys_updated_on falls after the stored watermark, ordered by that field, with sysparm_fields trimmed to the mapped columns. It follows the Link header from page to page, upserts into HubSpot as batches keyed on the sys_id, and then runs a separate association pass: contact to company, ticket to company and contact, contract to company. Each table’s watermark moves only after its batch commits, so a restart resumes rather than reloads.

A replay endpoint re-reads any table for a time window. A reconciliation endpoint compares the X-Total-Count header ServiceNow returns with the records in the portal and lists the difference. Where the platform team agrees, a business rule posts the sys_id of a changed case to our endpoint, which only tells the service to read sooner.

With nothing packaged on either side, the choice here is where the logic lives and who operates it. ServiceNow teams often prefer integrations built inside the instance, and Integration Hub is ServiceNow’s tool for that. It lists no HubSpot spoke, though, and which spokes a customer gets depends on its Integration Hub subscription, so building there means ServiceNow developers writing and owning calls to HubSpot’s API.

A custom API integration keeps the logic outside the instance. It asks the platform team for an integration user, an OAuth client and read access to four tables, and nothing more. An iPaaS with connectors for both systems sits in between: quick to start and fine for copying new cases, but harder to make replay a missed window or hold a separate watermark for each table.

1. Scope. We confirm whether customers live in Customer Service Management or IT service management, which tables matter, and who approves users, roles and rules on the platform team.
2. Architect. We fix the sys_id keys, a watermark per table, the case state to ticket status map and the association order, and route the one write back through a review queue.
3. Build. The service is written against a non-production instance cloned from production and a HubSpot sandbox, with instance and portal allowlists that fail closed.
4. Validate. We backfill every table, compare counts with X-Total-Count, and walk the differences with the ServiceNow owner.
5. Operate. Cutover is a credential swap. We watch 429s and run history, keep replay available, and re-test after each ServiceNow upgrade.