Custom HubSpot integration, built on the route that fits

A custom HubSpot integration is software written for one business’s systems rather than installed from a listing. It reads records from a source such as an ERP, a booking platform or a warehouse, writes them onto the right HubSpot objects, and often carries changes back the other way. Every record keys on the identifier the source already owns, held in a custom HubSpot property, so running the same window twice changes nothing that already landed.

What makes it custom is less the code than the decisions inside it. Which system owns each field. Which deal stages a sync may write, and which belong to a salesperson. What happens to a record the source deletes. Those answers differ for every business, and a packaged connector has to assume one set of them for everybody.

Start with the HubSpot App Marketplace. If an app carries your objects in the direction you need, install it and stop: setup is 8 to 24 hours, and the vendor maintains it from then on. The approach guide asks the questions in order, cheapest to answer first.

The marketplace stops being enough in a few recognizable places. Your records live in custom objects the app does not know. The source has no webhooks and no way to ask what changed since a timestamp, so something has to remember where it read up to. A rule has to decide at runtime, such as a paid invoice closing a deal unless a rep has already moved it. The system sits on premises or behind a partner gate. Or the volume passes about 10,000 records a day. Any one of those is reason to look at a build.

The routes differ, and the habits under our custom builds do not. Every object upserts on its source identifier. Associations run as a pass of their own once both records exist, and in a publisher’s order middleware anything that fails to resolve queues for repair rather than disappearing into a log. Where the source cannot report changes, the service keeps the memory: a watermark per flow, a checkpoint after every run, and a replay an operator can trigger. HubSpot API paths are pinned to version 2026-03, so a platform change cannot alter a running service underneath it.

Rate limits are designed in rather than discovered, on every route. HubSpot counts its burst limit per app, and every private app in an account draws on one daily budget, so reads are cached, batches are throttled, and a step that bursts through the budget waits instead of failing. A manufacturer’s nightly chain waits 15 minutes after its largest step for exactly that reason.

Somebody has to own an integration after it goes live, and we settle who at scoping. A pickleball franchise’s sync was on a server we ran and watched until the franchise took it over, and it now runs on the franchise’s own server, from its own repository, with its own tokens. A senior living operator’s sync runs as notebooks inside the operator’s own Microsoft Fabric tenant. A publisher’s order middleware is one deployable service on Railway, with PostgreSQL holding its run history and checkpoints, and an operations API for triggers and replays. Our own partner portal runs on Cloudflare.

Every build follows the same five stages, and each one produces what the next needs. How we scope an integration covers each stage in full, with what you receive and what we need from you.

1. Scope. We test the source against live responses rather than its documentation, and finish with the object list, the match keys and an effort band.
2. Architect. We settle the HubSpot object model, the key on every object and which side owns each record.
3. Build. The service is written against a HubSpot sandbox portal, never against production, with its code and runbook in their own repository.
4. Validate. We reconcile counts object by object, run the failure paths on purpose, and walk the portal with the people who will use it.
5. Operate. Cutover is a token swap behind a portal allowlist that fails closed. Then we watch the first runs, which is where the real operating knowledge appears.

Effort on this site is quoted in hours, never as a price. A light one-way build of three objects or fewer runs 40 to 60 hours, a standard two-way sync 70 to 150, and an enterprise build across several systems 300 to 450.