HubSpot + Procore integration

Construction firms buy Procore for the project and then discover it cannot tell them where the next one is coming from. Everything before the award lives somewhere else: the relationship with the owner, the architect who keeps recommending them, the invitation that arrived three weeks ago, the estimator’s judgement about whether this one is worth bidding. That history sits in inboxes and in one person’s memory.

The pattern is familiar to anyone who has tried to fix it. Someone buys a CRM, asks project managers to keep it current, and watches them not do it. They are not being difficult. A project manager’s day is in Procore, and a second system that asks for the same information twice is a system they will ignore. A design that depends on their goodwill will not survive contact with a live project.

So the useful question is which system owns what, not how to get construction people into a CRM. Procore is the record for cost, schedule and the project once it exists. HubSpot is the record for the relationship and the pursuit. A connection that respects that split can follow a firm from first contact through bid submission to award without asking anyone to retype anything, and it can show a business development lead which owners actually convert. A connection that ignores it produces two half-true copies of the same project and an argument about which number is right.

Six objects carry the pursuit. Bids become deals, because a bid is the one construction record that is won or lost once. Projects, bid packages and change orders become custom objects associated to the deal and to the company. The Procore company directory becomes HubSpot companies, and project directory people become contacts.

The directory is the piece worth care. Procore keeps owners, architects, engineers and subcontractors in one list, and a naive sync turns all of them into indistinguishable company records. A record type property set during the load keeps a subcontractor out of an owner-facing report, and it is far cheaper to set on the way in than to repair later.

Change orders earn their place in the sync for a commercial reason rather than a technical one. They are the clearest signal that a relationship is expanding, and an account manager who can see them has a reason to call before the project closes.

The shape is a webhook queue with a reconciliation sweep that is not optional. Procore is explicit that webhook delivery is best effort: events retry with backoff for up to twelve hours and are then discarded. A design that trusts the stream alone will lose records, quietly, on the day an endpoint is slow.

So events do the fast work and a scheduled pass does the honest work. The ingest endpoint verifies and acknowledges, a consumer fetches the full resource and upserts on the Procore id, and a sweep pages the collections on a longer cycle using page and per_page, comparing what Procore holds against what the portal holds. Rate limiting is read from the response headers rather than assumed, because Procore publishes two windows, hourly and spike, and asks you to follow the headers rather than a fixed number.

The first question is whether anything has to survive a lost event. If the integration only powers a notification, a per-task platform is fine and quick. If it powers a pipeline someone forecasts from, the best-effort delivery guarantee makes a reconciliation pass mandatory, and that pass needs somewhere to run.

The second question is the object model. Connectors sold on Procore’s own marketplace map a fixed set of fields in a fixed direction. When the firm’s pursuit process matches that shape, they are a reasonable buy. When bids, prequalification and change orders need to live in a pipeline the business recognizes, a build is what gets you there.

1. Scope. We map the firm’s real pursuit process, from invitation to award, and decide which stages belong in HubSpot at all.
2. Architect. Bids as deals, projects and change orders as associated custom objects, a record type on every directory company, and the reconciliation cadence agreed up front.
3. Build. Webhook ingest, queue, mapper and sweep against the developer sandbox and a HubSpot sandbox portal, with a portal allowlist that fails closed.
4. Validate. A full backfill with counts compared per object, then the directory duplicates we found in discovery.
5. Operate. Watch the sweep as closely as the stream, replay what the stream missed, and re-check the mapping when Procore moves an endpoint to a new version.