Connect Anything to HubSpot: A Complete Guide to Integrations

What a HubSpot integration is (and how data really flows in and out of your CRM)

A HubSpot integration is a connection that lets HubSpot exchange data with another system, such as your ERP, accounting platform, product database or support tool, so records stay consistent across both without anyone re-typing them. The connection moves data in, out, or in both directions, on a schedule or in real time, using each system's API.

That definition is deliberately broad, because the promise of this guide is broad: you can connect or integrate almost anything with HubSpot. The question is never really whether two systems can talk. With enough engineering, they can. The question is how they should talk, and that is the decision the rest of this guide is built to help you make.

Data flowing in and out

Every integration does one of two jobs, or both. Data flows in when another system writes to HubSpot, for example pushing paid invoices from your finance system onto the company record so sales can see who actually pays. Data flows out when HubSpot writes to another system, for example sending a closed-won deal into your ERP to trigger fulfilment. Most useful integrations do both, which is where the detail starts to matter.

Real-time versus batch

Timing decides what your team can trust. A batch (or scheduled) sync collects changes and moves them on an interval, perhaps every fifteen minutes or overnight. It is simpler and cheaper, and it is fine when a short delay does no harm. A real-time sync moves each change the moment it happens, usually triggered by a webhook from the source system. You need real time when a stale value causes a bad decision, such as a sales rep quoting against stock that sold an hour ago. The difference between the two is rarely about preference; it is about how quickly wrong data hurts you.

One-way versus two-way

Direction is the other axis. A one-way sync has a single source of truth and a single follower: the source writes, HubSpot reads, and HubSpot never writes back. A two-way sync lets both systems update the same fields, which is powerful and far harder to get right. Two-way sync needs clear rules for which system wins a conflict, how to avoid update loops, and how to map records that do not line up cleanly on either side. Getting those rules wrong is how teams end up with two systems that confidently disagree.

APIs and OAuth, in plain terms

The plumbing underneath all of this is the API: the defined set of requests a system accepts for reading and writing its data. HubSpot exposes a well-documented API; your other systems each expose their own, with their own limits, quirks and gaps. OAuth is the standard that lets one system act on another's behalf securely, using revocable tokens instead of shared passwords, with scopes that limit exactly what each connection can touch. When an API is modern and well documented, integration is straightforward. When it is undocumented, legacy or locked behind a firewall, the work moves from configuration to engineering.

Why this makes HubSpot a single source of truth

Done properly, integrations turn HubSpot from one more disconnected tool into the place your whole team trusts. Finance, fulfilment, product usage and support data all land against the right contact, company and deal, so people stop tab-hopping and stop guessing. That single, trustworthy view is also the foundation everything downstream depends on, including the live, two-way data a customer portal needs to be useful.

How you achieve that view depends on which of four integration methods you choose, and each has a point where it stops working. The next section sets out those four methods and the decision between them. If you want, you can skip ahead to that comparison, or talk to us about a custom HubSpot integration.

The four ways to integrate with HubSpot (native, Data Sync, iPaaS, custom)

Every HubSpot integration question eventually reduces to the same decision: which of four methods do you reach for, and where does each one stop working? The old framing of native versus middleware versus custom is still useful, but it collapses two genuinely different things (HubSpot's own Data Sync and third-party iPaaS tools) into one bucket and hides the trade-offs that actually bite in production. So we use four methods. Each has a legitimate place. The skill is matching the method to the job, not defending a favourite.

The governing principle is simple: buy the commodity, build the differentiator. If a clean, supported connector already moves the data you need at the volume and direction you need, use it and spend your engineering budget elsewhere. Reach for custom code when the connector hits a wall that matters to the business: custom objects, financial and ERP records, high volume, true real-time two-way sync, or a legacy or firewalled system with no usable API.

1. Native connector (app marketplace)

A pre-built connector you install from the HubSpot App Marketplace, configured with a few clicks. Best for mainstream SaaS tools (Slack, Zoom, common ad platforms, mainstream CRMs) where you want a standard, supported field mapping and nothing bespoke. Strengths: fast, cheap or free, maintained by the vendor. Limits: you take the mapping you are given, custom objects and edge fields are often unsupported, and you cannot change behaviour the vendor did not anticipate.

2. HubSpot Operations Hub Data Sync

HubSpot's own two-way sync engine, built into Operations Hub, with first-party connectors for popular apps plus default and custom field mappings. Best for keeping contacts, companies and a defined set of properties in step between HubSpot and another supported system. Strengths: genuinely two-way, historical sync, sensible conflict handling, no third-party tool in the middle. Limits: it syncs the object and field types HubSpot supports; deep custom objects, financial records and bespoke business logic sit outside it.

3. No-code and iPaaS (Zapier, Make, Workato)

A third-party automation layer that connects apps via triggers and actions. Best for event-driven workflows across many tools, quick internal automations, and stitching together long-tail apps that have no native connector. Strengths: huge app coverage, fast to build, accessible to non-engineers. Limits: it polls rather than syncs in real time, costs scale with task volume, and it becomes brittle and hard to debug once flows branch, retry and depend on each other. It is automation glue, not a system of record sync.

4. Custom real-code integration

A bespoke integration built against the HubSpot API and the other system's API (or its database, message queue or file drops where no clean API exists). Best for the cases the first three cannot reach: ERP and finance data, custom objects, high volume, guaranteed real-time two-way sync, and undocumented, legacy or firewalled systems. Strengths: it does exactly what the business needs, with proper error handling, observability and ownership of the logic. Cost shape: a higher build investment, then low marginal cost to run and extend. This is where we spend most of our time, and it is the method behind the integrations we have delivered across more than 300 projects.

The four methods at a glance

Method	Best for	Strengths	Limits	Cost shape
Native connector (marketplace)	Mainstream SaaS, standard field mappings	Fast, cheap, vendor-maintained	Fixed mapping; no custom objects or bespoke logic	Free or low subscription
Operations Hub Data Sync	Two-way sync of standard objects and properties	First-party, two-way, historical sync, no middleman	Supported objects only; not for ERP or deep custom data	Hub subscription tier
No-code / iPaaS (Zapier, Make, Workato)	Event-driven automations across many apps	Broad app coverage, quick, non-engineer friendly	Polling not real time; brittle at scale; per-task cost	Usage-based, rises with volume
Custom real-code	ERP, custom objects, high volume, real-time two-way, legacy APIs	Exact fit, robust, observable, owned	Higher upfront build; needs engineering	Build investment, low cost to run

In practice most mid-market stacks use a mix: a native connector for the mainstream tools, Data Sync for the core CRM objects, an iPaaS flow or two for lightweight automation, and custom code for the one or two integrations that carry real commercial weight. The mistake is forcing a single method onto everything, either over-engineering a Slack notification or trying to bend Zapier into a real-time ERP sync it was never built to handle.

The first three methods cover the commodity work. When the decision narrows to "use the connector or write the code", and you already know you need bespoke engineering, our custom HubSpot integration work is where this thinking gets built.

Where each method stops working

Every integration method earns its place until the moment your data outgrows it. Native connectors, Data Sync and iPaaS tools are not bad engineering; they are bounded engineering. They hold a fixed contract about what HubSpot objects exist, how fast records change, and how cleanly the other system exposes its data. The day your business breaks one of those assumptions, the method quietly starts to leak. The skill is recognising the boundary before it costs you a quarter of clean reporting. Here are the five triggers that push you off the shelf and toward custom HubSpot integration.

Custom objects

Native connectors and most no-code tools speak fluent contacts, companies and deals. They go quiet the moment your model needs HubSpot custom objects: subscriptions, sites, vehicles, policies, projects. The connector either cannot write to the object at all, or it can create records but not maintain the associations that make them useful. If your sales and service teams live in a custom object that your sync tool treats as a second-class citizen, you have already outgrown the connector.

ERP financial objects

Invoices, orders, credit notes and entitlements live in your ERP, not in a marketing schema. No native HubSpot connector models a Sage or NetSuite invoice line with its tax, currency and payment status intact. iPaaS can move the headline fields but loses the structure, and the structure is the point. When finance asks why the revenue in HubSpot does not reconcile with the ledger, the answer is almost always that a no-code tool flattened an ERP financial object into a note field.

High volume and API rate limits

No-code tools bill per task and run on shared infrastructure, so volume hits you twice. A sync that is fine at a few hundred records a day falls over at tens of thousands: tasks queue, costs climb, and you start tripping HubSpot or source-system API rate limits with no backoff strategy of your own. A practical sign is that your Zapier or Make bill has become a line item finance asks about, or that records now arrive hours late.

True real-time two-way sync

Data Sync and iPaaS mostly poll: they check for changes on a schedule, so "real time" is really "every few minutes, in one direction at a time". That is fine for a contact list and dangerous for stock levels or order status. If two systems can both edit the same record and you need changes reflected in seconds without overwriting each other, you need event-driven, conflict-aware engineering rather than polling.

Undocumented, legacy or firewalled systems

The shelf assumes a clean, documented, public REST API. Plenty of mid-market estates run on something older: a legacy ERP with a SOAP endpoint, a bespoke database behind a firewall, or a vendor system whose API is undocumented or off-limits. No connector exists, and no iPaaS template will appear. This is where real code, secure tunnelling and reverse-engineered contracts become the only route, and it is the work our custom HubSpot integration team takes on as standard.

How to tell you have outgrown the tool

You rarely hit one trigger cleanly; you accumulate them. The honest tests: you are maintaining manual workarounds for things the sync should handle, your tool bill scales with growth rather than usage, reporting needs a caveat before anyone trusts it, or a sync failure now counts as an incident. If two or more of those are true, it is worth comparing the real total cost of ownership against a properly engineered custom HubSpot integration before you renew another no-code subscription.

Connecting legacy, ERP and proprietary systems to HubSpot

This is where the integration questions stop being about which connector to install and start being about engineering. The four methods covered above all assume one thing: that the system on the other side exposes a clean, documented, modern API and will let you talk to it over the public internet. A large share of the systems that actually run a mid-market business do not. The finance team's ERP, the warehouse system written fifteen years ago, the bespoke database sitting behind a corporate firewall, the supplier feed that only arrives as a file at 2am. These are the systems that hold the data HubSpot most needs, and they are exactly the ones no-code tools cannot reach.

Why undocumented and legacy systems defeat no-code tools

Native connectors, Operations Hub Data Sync and iPaaS platforms like Zapier or Make all rely on a pre-built bridge to the other application. That bridge only exists for popular, well-documented, cloud-hosted software. The moment you point them at something proprietary, they have nothing to connect to. There is no listing in the marketplace, no trigger to subscribe to, no authentication flow that fits the boxes the tool expects. Even where a legacy system technically has an API, it is often undocumented, returns inconsistent data, has no webhooks for change events, or rate-limits so aggressively that real-time sync is impossible. No-code platforms have no way to compensate for any of that. They are designed to wire together systems that already want to be wired together.

ERP and accounting systems are the sharpest example. Sage, NetSuite and Microsoft Dynamics hold invoices, order lines, credit status and financial objects that map to no standard HubSpot object. Their data models are deep and unforgiving, their APIs vary by version and deployment, and on-premise installations frequently sit behind a firewall with no inbound access at all. Getting clean, current financial data from one of these into HubSpot is a data-engineering problem, not a configuration task.

What real-code integration actually does here

Reaching these systems means writing real code and standing up proper infrastructure, not stitching templates together. In practice the work involves several techniques that no-code tools simply do not have:

• Undocumented and legacy APIs require reverse-engineering the behaviour of the endpoints, building a resilient client that handles the system's quirks, and managing authentication schemes that predate modern OAuth.
• Firewalled and on-premise databases need a secure agent or middleware component running inside the customer's network, polling or reading the database directly and pushing changes out over an encrypted channel, so HubSpot never needs direct access to the protected system.
• SFTP and file-based exchange remains how a great many ERPs and older platforms share data. That means parsing CSV, fixed-width or XML files on a schedule, validating and de-duplicating records, and transforming them into the shape HubSpot's objects expect before anything is written.
• ERP and accounting objects need a deliberate data model: mapping financial records to custom objects, preserving relationships between companies, deals and invoices, and reconciling differences so the two systems stay trustworthy over time.

All of this depends on a layer that sits between the systems, handles transformation and error recovery, retries failed writes, logs every sync, and alerts someone when an upstream system changes. That is engineering and data-engineering discipline, and it is the foundation everything else stands on.

This is the SpotDev wedge. As a Custom Integration Accredited partner that has delivered integrations across more than 300 projects, we build the pipelines, models and middleware that move trustworthy data between HubSpot and systems no connector will ever support. If your project hinges on getting clean, reliable data out of a difficult source system, see how we approach custom HubSpot integrations, grounded in our data engineering practice.

Real-time, two-way sync and the architecture underneath

"Integrated" can mean almost anything. The difference between an integration you can trust and one that quietly drifts comes down to architecture: how changes are detected, which direction data flows, how records are matched, and what happens when something fails. Get those four things right and the sync becomes invisible infrastructure. Get them wrong and you spend every quarter reconciling spreadsheets by hand.

Webhooks versus polling, real-time versus batch

There are two ways to move a change between systems. Polling asks the source system "what changed since last time?" on a schedule, every fifteen minutes, every hour, overnight. Webhooks flip it round: the source system pushes a notification the moment a record changes, and the integration reacts immediately. Polling is simpler and works against almost any API, but it adds latency and burns through rate limits checking for changes that mostly are not there. Webhooks give you genuine real-time sync, but the source system has to support them and you need somewhere reliable to receive the events. In practice a robust integration uses both: webhooks for the events that need to be instant (a deal closes, a payment clears) and scheduled batch jobs for bulk reconciliation that catches anything a webhook missed.

Two-way sync, data mapping and deduplication

One-way sync is easy because there is only ever one source of truth. Two-way sync is where the engineering lives, because the same record can change in both systems at once. You need a clear field-level mapping that says which system owns which attribute, and conflict rules for when both sides edit the same field, usually last-write-wins with a timestamp, or a defined master per field. You also need deduplication that does not rely on a shared primary key, because HubSpot and an ERP rarely share one. Matching on email, company number, or a composite key, then merging rather than duplicating, is what stops the same customer appearing three times. Loops are the other hazard: System A writes to B, which fires an event that writes back to A, forever. Sound integrations stamp the origin of each change so a synced update never echoes back as a new one.

Error handling, retries and reliability

APIs fail. They time out, hit rate limits, and return malformed payloads, and a production integration has to assume this rather than hope it away. That means idempotent writes so a retried message does not create a duplicate, exponential backoff so a struggling system is not hammered, dead-letter queues so a failed record is parked for inspection instead of silently dropped, and alerting so a human knows before the customer does. This reliability layer is the unglamorous majority of the work, and it is exactly what separates a real integration from a no-code flow that breaks the first time an endpoint hiccups. It is engineering, which is why this sits alongside our wider data engineering practice.

Why portals and live dashboards depend on it

This architecture is not optional once you put data in front of a customer. A customer portal or a live dashboard shows a balance, an order status, or a support ticket, and the person reading it expects it to be correct right now, not as of last night's batch. A portal needs live, two-way data underneath it: read the current state in real time, and write the customer's action straight back to the system of record. Stale or one-way data turns a portal into a liability, because a wrong number on a screen is worse than no number at all. That is why we treat portals and integrations as the same problem, a point we expand on in customer portals for mid-market B2B. When the sync is trustworthy, everything you build on top of it is too.

Security, UK GDPR and data governance

Every integration is a standing permission for one system to read and write data in another. That is fine when it is scoped and documented, and a liability when it is not. The questions your IT and security teams will ask are predictable, so design for them up front rather than retrofitting answers during a security review. The practical concerns fall into four areas: access scope, data in transit, who can see what, and which system is allowed to be wrong.

OAuth scopes and least privilege

A HubSpot integration authenticates through OAuth, and the scopes you grant define exactly what it can touch. Grant the narrowest set that does the job. If a sync only needs to read deals and write a single line-item property, it should not hold write access to contacts, tickets and your whole CRM. Use a dedicated connected app or service account per integration so access can be audited and revoked independently, and rotate credentials on a schedule rather than treating them as permanent. Least privilege is not bureaucracy here. It is the difference between a misbehaving sync touching one object type and it rewriting records across your CRM.

Data in transit and at rest

Traffic between systems should be TLS-encrypted end to end, with no plaintext API calls and no credentials in query strings or logs. Where you control the integration layer, terminate connections to known hosts only and keep secrets in a managed store, not in code or environment files that get committed by accident. For systems behind a firewall, prefer an outbound connection or a controlled relay over opening inbound ports. These are the controls a security questionnaire will probe, and they are far cheaper to build in than to add later.

Who can see what

An integration can quietly widen access. If a finance system's invoice data lands on the contact record, every user who can open a contact can now see it. Map field-level visibility before you sync, not after. Decide which fields are genuinely needed in HubSpot, keep sensitive financial or personal data out unless there is a real use for it, and use HubSpot's property-level permissions and team partitioning to contain the rest.

UK GDPR and data residency

Under UK GDPR you need a lawful basis for moving personal data between systems, and you need to know where it physically sits. HubSpot offers EU data hosting; confirm which region your portal and any middleware actually use, and check that an iPaaS step is not routing data through a region you have not signed off. Keep a record of what personal data each integration moves and why, honour deletion and rectification requests across every connected system, and make sure a contact erased in HubSpot does not survive in the system it syncs with.

Source-of-truth governance

The single most useful governance decision is naming, per field, which system owns the truth. The ERP owns invoice totals; the CRM owns deal stage; one system owns the email address. Without that, a two-way sync will overwrite good data with stale data and nobody will know which value to trust. Document ownership before you wire anything together. We treat this as the foundation of any sync we build into our data engineering work, and the same controls underpin every custom HubSpot integration we deliver.

How to scope and cost a HubSpot integration

There is no list price for a HubSpot integration, and anyone who quotes one before understanding your systems is guessing. The cost is driven by engineering scope, and the same two systems can be a week of work or a multi-month build depending on the answers to a handful of questions. Scoping is the process of pinning those answers down before a line of code is written, so the number reflects the actual work rather than an optimistic estimate.

These are the drivers that move the figure most:

• Number of systems. Connecting HubSpot to one system is a single integration. Connecting three is three integrations plus the orchestration between them, and the cost rarely scales linearly because each system adds its own auth, rate limits, and edge cases.
• Direction. Reading data out of a system one way is far cheaper than a true two-way sync, where conflict resolution (which side wins when both change a record) becomes the hard part. If you need genuine bidirectional flow rather than a one-directional feed, expect a step change in effort.
• Volume. A few hundred records a day and millions of records with frequent updates are different engineering problems. High volume forces decisions about batching, queues, and API rate limits that low-volume builds can ignore.
• Custom objects and financial objects. Standard contacts and companies map cleanly. Custom objects, line items, and ERP financial objects (invoices, orders, ledger entries) need bespoke mapping and validation, and they are where native connectors and data-sync tools usually stop.
• Real-time versus batch. A nightly batch is tolerant of failure and easy to re-run. Real-time, event-driven sync needs webhooks, retries, and monitoring so nothing is silently dropped. The closer you get to true real-time, the more infrastructure sits behind it.
• Data quality. Clean, well-structured source data is cheap to map. Inconsistent formats, duplicates, and missing keys mean cleansing and matching logic before anything syncs, and that work is easy to underestimate.
• Undocumented or legacy APIs. A modern, well-documented REST API is the best case. Legacy ERPs, firewalled systems, and undocumented or partial APIs require reverse-engineering and defensive handling, and this is consistently the biggest single multiplier on cost.

To scope properly, document each system you want to connect, the exact objects and fields involved, the direction and frequency of sync, your daily and peak record volumes, and the state of the source data. Be honest about which systems have a usable API and which do not. That single document turns a vague request into a quotable build, and it is the same information that determines whether a custom HubSpot integration is the right method or whether a lighter approach will hold.

When you are ready to put real numbers against your own systems, take your scoping notes to the HubSpot integration specialists at SpotDev for a proper quote rather than a guess.

Why SpotDev for HubSpot integrations

Most agencies stop at the connectors HubSpot ships in the box. We start where those run out. SpotDev is a HubSpot Diamond partner with the Custom Integration Accreditation, a credential held by roughly the top 2% of UK partners, and we have delivered integrations across 300+ projects. That means real code, not a Zapier zap holding two systems together with string. When a native connector or Operations Hub data sync genuinely fits, we will tell you to use it and save your budget. When it does not, we build the thing that actually holds.

The integrations that break the standard toolset are the ones we specialise in: custom CRM objects, financial and ERP objects, high record volumes, true real-time two-way sync rather than overnight polling, and legacy or firewalled systems whose APIs are undocumented or barely documented at all. We have connected Sage, NetSuite, Dynamics and in-house platforms that the no-code tools simply cannot see. If your finance team needs invoices, credit limits and order status reflected in HubSpot the moment they change, and changes in HubSpot written back without a human re-keying anything, that is custom real-code territory and it is the work we do every week.

We build for the mid-market: B2B companies turning over £3m to £50m with 30 to 500 people. At that size you have real systems, real data volumes and real compliance constraints, but rarely a spare in-house integration team to own a bespoke connector for years. So we engineer integrations to be maintainable, monitored and owned past go-live, not handed over as a black box that nobody dares touch.

Live, two-way data is also the foundation the next layer of your customer experience stands on. The customer portals we build for mid-market B2B only work because the data behind them is correct in real time: a portal showing yesterday's order status or a stale balance erodes trust faster than no portal at all. The integration engine is the unglamorous part that makes the visible edge dependable. If portals are on your roadmap, get the sync right first.

If you want code-level engineering rather than another middleware subscription, the place to start is our custom HubSpot integration service. Tell us which systems need to talk, in which direction, and how fresh the data has to be, and we will tell you honestly whether you need a connector, a sync or a build. Where the answer is a build, you will be working with one of the few UK teams accredited and proven to deliver it.

Frequently asked questions

How much does a HubSpot integration cost?

It depends entirely on method. A native marketplace connector is usually included with your subscription or a small monthly add-on. Operations Hub Data Sync needs a Hub licence. No-code and iPaaS tools (Zapier, Make, Workato) carry per-task or per-operation pricing that climbs with volume. A custom real-code integration is a project cost that scales with the number of objects, the volume of records, and how awkward the source system is.

Native connector vs middleware/iPaaS vs custom: which do I need?

Use a native connector when a supported app does exactly what you need. Use iPaaS for light, event-driven automation between well-documented apps. Choose custom when you hit custom objects, ERP financial records, high record volume, true real-time two-way sync, or systems with no usable API. If you want help weighing it up for a specific build, talk to us about a custom HubSpot integration.

How long does a HubSpot integration take?

A native connector takes minutes. Data Sync and a simple iPaaS workflow take hours to days. A custom integration typically runs a few weeks, covering data mapping, build, testing against real records, and go-live. Complex ERP or legacy work takes longer because the discovery and reconciliation work is the hard part, not the writing of code.

Can a HubSpot integration sync two-way?

Yes, but not every method does it well. Many connectors and polling-based tools sync in one direction or on a schedule, which leaves your systems briefly out of step. True real-time, two-way sync with conflict handling needs a properly engineered approach, which is the kind of build we deliver as a custom HubSpot integration.

Is my data secure?

A well-built integration authenticates over OAuth or scoped API keys, moves data over encrypted connections, requests only the permissions it needs, and logs every sync for auditing. The risk sits in the design, not the act of integrating. Custom builds let you control exactly what is shared, where it is processed, and how failures are handled.

Can you integrate an undocumented or legacy system?

Yes. This is the core of what we do. Where there is no public API, we work with legacy and ERP endpoints, undocumented interfaces, and firewalled systems to build a reliable connection. As a Custom Integration Accredited Diamond partner with integrations delivered across 300+ projects, we write real code rather than forcing a workaround.

Do I need Operations Hub?

Only for Data Sync and HubSpot's native data-quality and programmable-automation features. A custom integration does not require Operations Hub, because it talks to the HubSpot API directly. If you already hold the licence, Data Sync can be a sensible first option for supported apps.

Where should I go next?

For a commercial conversation about a build, see our custom HubSpot integration service, or find your specific tool in the integration library. If you are moving CRM rather than syncing, start with data migration.

Explore the HubSpot integration series

Go deeper on the methods and decisions in this guide:

• HubSpot integration methods: native, Data Sync, iPaaS or custom
• Native vs custom: when to build vs buy
• Zapier vs a custom HubSpot integration
• Real-time, two-way sync explained
• Connecting legacy, ERP and undocumented systems
• How much does a custom HubSpot integration cost?