HubSpot + Jobber integration

The call usually comes from a home service business that has outgrown one office. Jobber runs the day: a technician quotes in the driveway, the office schedules the visit, the invoice goes out that evening. HubSpot runs the demand: the paid search, the review request, the seasonal campaign to last year’s customers. Neither side can see the other, so nobody can say which campaign produced the work that actually got paid for.

What that costs is specific. Marketing reports on form fills because form fills are all it has, while the owner cares about approved quotes. A quote sits unaccepted for nine days and nothing chases it, because the follow-up sequence lives in a system that never heard about the quote. The same customer gets a new-customer email a week after their third job. Each of these is small on its own, and together they are the reason a branch manager keeps a spreadsheet.

There is a second, quieter reason. Home service businesses grow by acquisition and by adding trades, and each addition arrives with its own Jobber account and its own idea of what a client record looks like. A CRM that holds the relationship, with jobs and invoices hanging off it, is the only place that merge can happen without the field noticing. That is a data model decision before it is an integration, and it is worth making before anyone writes code.

Six objects carry almost every Jobber engagement. Clients become companies, their people become contacts, properties become a custom object, quotes become deals, and jobs and invoices become custom objects associated back to the client and the property.

The key is the Jobber id, stored in a custom HubSpot property and set as the unique identifier that batch upserts match on. HubSpot’s batch upsert takes an id property explicitly and handles a hundred records a call, which is what makes an idempotent load possible. Email is the wrong key here and the mistake is easy to make: a landlord holds four properties under one address, a couple shares an inbox, and a client who moves house keeps the same id while everything else about them changes.

Direction follows ownership. Quotes move both ways because sales genuinely works them in the portal. Jobs and invoices move one way only. Jobber is the system of record for scheduled work and for money, and a CRM that can edit either one will eventually be asked to explain a number it invented.

The shape is a webhook queue. Jobber posts an event, the service verifies the signature, acknowledges it inside a second and enqueues an envelope. Nothing slow happens in the handler, because a handler that calls an API is a handler that times out. A consumer then fetches the full record, maps it, compares a content hash against the last write and does nothing at all when nothing changed.

State lives in a link store: the Jobber id, the HubSpot id, the hash of the last payload, which side wrote last, and a short marker that stops the service reacting to its own write. Watermarks sit beside it, one per object, so a reconciliation sweep can ask Jobber for everything updated since the last good run and feed the same queue the webhooks feed. Replay is therefore ordinary: the sweep and the events converge on one code path, and a failed batch goes to a dead letter queue with enough envelope to run it again.

Volume and latency settle this one. Count the quotes and jobs a month. Under a few hundred, with one trigger that matters, a per-task automation platform is a sensible place to start and cheap to abandon. Above that, per-task pricing tracks the size of the business rather than the value of the integration.

The second question is whether anything has to survive a failure. A platform that fires and forgets is fine for a notification and wrong for a sync, because there is nowhere to store the link between a Jobber id and a HubSpot record, and nowhere to put the rule that decides who wins a conflict. Those two needs are what a written service exists for.

1. Scope. We count quotes, jobs and invoices a month, list the fields each team actually uses and agree which side owns each one.
2. Architect. Keys, direction and conflict rules written down first, then the object model, including whether jobs belong on a custom object or nowhere.
3. Build. Webhook ingest, queue, mapping and link store against a Jobber test account and a HubSpot sandbox portal, with a portal allowlist that fails closed.
4. Validate. A full backfill into the sandbox, counts reconciled object by object, then the awkward records we found in discovery.
5. Operate. Watch the dead letter queue, replay what fails, and revisit the mapping when Jobber ships a schema change.