HubSpot + Fieldwire integration

Fieldwire lives on the jobsite. Foremen and superintendents open it for the current plan sheet, the punch list and the day’s inspection forms, and a trade contractor may run it on projects for the general contractor who hired them. The business development side of the same firm works in HubSpot, pricing the next bid for those same general contractors, and it cannot see how the current project is going.

That blind spot costs real conversations. An account manager calls a client the week a punch list balloons, or misses the moment a project reaches closeout, a natural time to ask a satisfied superintendent about the next job. The people who know are in the field, and they will not retype their progress into a CRM, nor should they have to.

Fieldwire, part of Hilti Construction Software, exposes the same REST API that powers its own web and mobile apps, and it says many of its largest customers use it for import, export, analytics and automation. The real work is deciding what an account team needs from a jobsite system, which is far less than everything, and starting the project in Fieldwire from the deal that won it, so nobody types the job twice.

Four records matter. The project is the hinge: a closed won deal creates it in Fieldwire, and from then on Fieldwire owns it, so its status and dates come back to a HubSpot custom object associated to the deal and the client company. Project users become HubSpot contacts, keyed on email with the Fieldwire user id as the tie breaker, because the superintendent on today’s job is often tomorrow’s referral.

Tasks are where restraint pays. A busy project holds thousands of them, and a CRM record per punch item would bury the account team. We roll tasks up into counts by status on the project record and leave the tasks themselves in Fieldwire. Forms get the same treatment: a submitted inspection or daily report becomes one dated note on the project with a link back, rather than a copy of every field.

Everything keys on Fieldwire ids, which for projects are GUIDs, and never on a name. Field teams rename projects, and a key built on the name would split one job into two records.

The backbone is polling on a watermark, because Fieldwire built its pagination around one. List calls return an X-Last-Synced-At header, and the next call passes that value back as last_synced_at, so a service that stores it per project and record type resumes exactly where it stopped. Pages hold up to 1,000 items, set with the Fieldwire-Per-Page header, and updated_at filters narrow a backfill.

Authentication runs in two steps. A long-lived API token from the account page is exchanged at one account endpoint for a short-lived access token, whose lifetime Fieldwire can change without notice, so the service renews on a 401 rather than on a timer. Project data is regional: projects live in the US, the EU or Canada, each with its own base URL, while account data sits on a single global host. The service stores each project’s region beside its id and pins a Fieldwire-Version date on every call, since an unpinned call takes the latest version.

The write the other way is short. When a deal closes, a HubSpot workflow calls the service, which creates the project and stores the returned id on the HubSpot project record.

Two questions decide the route. The first is whether your account has API access at all: Fieldwire provides it on Enterprise-level contracts, or as an addition to Pro, Business and Business Plus arranged through its sales team, and without it no route exists. The second is whether anything has to flow back. Creating a project when a deal closes is one call, and an iPaaS with generic HTTP steps can make it. Bringing task counts, forms and contacts back to HubSpot needs a stored cursor per project and per region, and that is a service’s job rather than a per-task flow’s. Nothing in the HubSpot App Marketplace changes that choice, because nothing there is built for Fieldwire.

1. Scope. We confirm API and developer access on your Fieldwire account, list the regions your projects sit in, and agree which task statuses and forms an account team needs to see.
2. Architect. Deal to project in one direction, status, contacts and notes in the other, a cursor per project and record type, and a pinned version date.
3. Build. Fieldwire publishes no sandbox, so the service is written against a test project we agree with you in your own account, which the API itself can create, and a HubSpot sandbox behind a portal allowlist that fails closed.
4. Validate. We backfill a finished project, compare task counts and form notes with Fieldwire’s own views, and check that one won deal creates exactly one project.
5. Operate. We watch cursor age per project, move the version date deliberately, and widen webhook use as Fieldwire takes the feature out of development.