HubSpot integration engineering
HubSpot is easy to change, which is why so much of a business ends up living inside it. The trouble starts when the process outgrows the fields, because a workflow built in a CRM cannot be reviewed, tested or rolled back.
01Capabilities
The four jobs on the software either side of the CRM
This is an integration page rather than a HubSpot agency page. What we build is the software on both sides of the boundary and the connection that keeps them telling the same story, which is platforms development and integration work.
- Signals
Product state arriving as events, not as a spreadsheet
Signup, activation, usage and billing state landing as properties and events, so that sales and support see the same reality the product does. This is the integration that changes how a team works, and it is usually the one nobody has built yet.
- Sync
Two-way movement with explicit conflict rules
Orders, subscriptions and support state moving in both directions, with a written rule per field for conflicts and a way to replay after an outage. It matters anywhere the CRM sits beside real operations, including e-commerce, where order state changes constantly.
- Objects
Modelling only what earns its place in the CRM
Your real entities modelled in HubSpot where they belong, and kept out on purpose where they do not. Forcing a complicated domain into CRM objects produces a CRM nobody trusts and reports nobody opens.
- Consent
Forms and tracking that match the policy
Form delivery, event tracking and consent behaviour built to match the policy your legal side has actually set, not the one the tooling assumes. We build what the policy says, and we flag where the plumbing and the policy disagree.
02Fit
What the CRM should hold, and what it should only display
HubSpot is easy to integrate with and easy to overload, and the second part is what causes the damage. Every workflow built inside it is code with no repository, no review, no tests and no deploy history. That is fine for marketing automation and a poor home for anything the business depends on. Five of the six rows below send you somewhere other than a HubSpot project with us, and three of those name no unicrew page at all.
| Your situation | What we recommend |
|---|---|
| Marketing and a light sales process, a small team, nobody administering it full time | Use HubSpotThis is exactly what it is good at. The low administration burden is a real advantage, not a limitation you have to work around. |
| Territories, approval chains, bespoke quoting, and somebody whose job is the CRM | Different pageOur Salesforce page. HubSpot can be bent that far, and what you get back is a system that fights you at every process change. |
| You want product usage inside the CRM so sales can score on it | Events, not tablesSend lifecycle events and a small set of derived properties. The CRM is a view of the customer relationship, not a second copy of your application state. |
| Billing or subscription state decides what a customer is entitled to | Keep it in your systemLet the CRM display that answer and never own it. A support agent reading a stale field and telling a customer the wrong thing is a self-inflicted problem. |
| You want the CRM running operational workflows the business depends on | We argue againstPut that logic in a service with tests and version control, see business process automation. CRM workflows resist review and debugging at exactly the moment you need neither to be hard. |
| You already run both HubSpot and Salesforce | Decide the record firstName the system of record per object before integrating anything further. Two CRMs without that decision is a permanent reconciliation job somebody does by hand. |
Scope
What we own here is the boundary and how it behaves. The property model. The direction of each flow. How a conflict resolves when both sides changed. What happens to a queued event when HubSpot rate-limits us mid-campaign. unicrew has been building custom software since 2012, with 100+ senior in-house engineers across six countries. We work under an ISO 27001:2022 certified information-security management system. Your team keeps owning the portal, which is right, because they are the ones living in it.
03Delivery
The order that keeps an integration from being rebuilt in two years
Four steps. The first is a modelling conversation rather than code, and skipping it is why so many CRM integrations get thrown away and written again.
- Agree the object and property model firstWhich objects exist, which properties the integration writes, and which stay under human control. A property written by both a person and a machine is the single most reliable source of CRM data nobody believes.
- Send events, not database dumpsMeaningful lifecycle events and derived values, batched sensibly and sized against the API limits. Syncing everything because it is easy produces a CRM that is slow, expensive and impossible to report on.
- Write down what happens when both sides changeA rule per field for the case where both systems moved since the last sync, implemented rather than assumed. Last write wins is a decision, so make it one you took on purpose.
- Instrument the failuresAlerting on divergence and on a stalled queue, plus a reconciliation job, verified through the same QA and test automation practice as our own builds. A silent failure otherwise gets found by a salesperson reading a stale record.
04Stack
The systems this integration has to keep honest
The other CRM the choice is usually made against, and the parts we build on our own side of the boundary. Each has its own page.
05Questions
Questions that come up before the first integration
What a first conversation about a CRM boundary usually covers.
For the engineering around HubSpot, yes: engineers to build the integration, the services and the data path, working inside our delivery model rather than as a pair of hands. An architect outside the delivery team reviews the property model and the sync design, and the code goes through the same QA practice as our own. Capacity is managed teams; an outcome is platforms development and integration.
No. We are the engineers who connect HubSpot to the software around it, and who will tell you which automation belongs in your own codebase instead. Portal setup, campaign work and CRM administration are a different discipline and a different supplier. Where a project needs both, we work alongside whoever runs your portal, and each side owns its half.
Answer one question first: will somebody own the CRM as part of their actual job? If yes, and the process involves territories, approval chains or bespoke quoting, Salesforce will model it properly. If no, HubSpot stays coherent without a dedicated administrator, which is worth more than the modelling power you give up. Small teams buying Salesforce for a process they do not have yet run it worse.
Marketing scoring and campaign automation belong in HubSpot, because that is the job it is built for and the people who change it are the people who understand it. Anything the product or billing depends on belongs in your own code: entitlement, provisioning, dunning, anything with a compliance implication. The test is whether you would be happy explaining, in an incident review, that the rule lived in a workflow with no version history.
A scoping call with an engineer. Beforehand we want the property list, the objects you use, and an honest description of how data reaches the CRM today, including every manual step. What comes back is written: the property model, the direction of each flow, and the automation we would move out of HubSpot. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, offered once the first read is done, because a fixed number on a setup nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Is the process outgrowing what the CRM can safely hold?
Tell us what data has to cross the boundary and which side should own it. You get an engineer's read on the design, including the automation we would keep out.