Real-time, two-way HubSpot sync versus polling connectors

Most HubSpot integrations claim to "sync" your data. Far fewer do it in real time, and fewer still do it reliably in both directions. If you are running live dashboards, customer portals or any workflow where a sales rep and a finance system need to agree on the same number, the difference between a real-time, two-way sync and a polling connector is the difference between data you can act on and data you have to second-guess.

This article walks through how real-time, two-way sync actually works under the bonnet: webhooks versus polling, real-time versus batch, how conflicts get resolved when both sides change a record, and what it takes to keep mapping and deduplication honest over time. It sits beneath our main guide on how to connect anything to HubSpot, which covers the four integration methods in full.

Polling versus webhooks: two ways to move the same data

Every integration has to answer one question: how does System B find out that something changed in System A? There are two broad mechanisms.

Polling means the integration asks, on a timer, "has anything changed since I last checked?" Every five minutes, every fifteen minutes, sometimes once a night, it pulls a batch of records, compares them and writes the differences across. It is simple to build and works against almost any system that exposes a read API.

Webhooks invert the model. Instead of asking repeatedly, the integration subscribes to events. When a record changes, the source system pushes a notification immediately, and the integration reacts to that single event. HubSpot supports this both ways: it can send webhooks out when CRM objects change, and it accepts writes back the moment your other system fires its own event.

Polling is not wrong. For a nightly reconciliation between HubSpot and an accounting ledger, a batch job is perfectly sensible. It falls short the moment a human or a screen is waiting on the result. A customer logs into a portal and sees an order status that is fifteen minutes stale. A sales manager refreshes a dashboard and the pipeline figure lags reality. Those are not edge cases; they are the everyday experience of a polling sync running on a generous interval.

Real-time versus batch: when latency becomes a defect

"Real time" is often used loosely. In practice it means the change propagates fast enough that no user notices a gap. Batch means changes are deliberately collected and processed together at intervals.

The right choice depends on who consumes the data. A finance team closing the month can work happily off a batch sync. A customer portal cannot. Portals and live dashboards need live, two-way data because the person looking at the screen expects it to be correct now, and they expect their own changes, a status update, an uploaded document, a support reply, to be reflected back into HubSpot without delay. The instant you put a customer in front of the data, latency stops being a performance metric and becomes a trust problem.

Two-way sync and the conflict problem

One-way sync is comparatively easy. System A is the source of truth, System B mirrors it, and you never have to ask which version wins. Two-way sync is harder because both systems can change the same field, and at some point they will disagree.

Imagine a contact's phone number is updated in HubSpot by a sales rep at the same time a support agent updates it in your other platform. Which value is correct? A serious integration decides this on purpose rather than by accident. Common strategies include:

• Source of truth per field. The phone number is always owned by the CRM; the order status is always owned by the ERP. Conflicts cannot occur because only one side is ever allowed to write a given field.
• Last write wins, with timestamps. The most recent change is kept. This only works if both systems give reliable, comparable timestamps, which is less common than people assume.
• Merge rules. Some fields combine rather than overwrite, for example appending to an activity log instead of replacing it.
• Human review queues. Genuinely ambiguous conflicts are flagged for someone to resolve, rather than silently picking a winner.

The failure mode of cheap two-way connectors is that they pick "last write wins" by default and hide it from you. Two systems then quietly fight over a field, each overwriting the other on every cycle, and your data flickers between two values. Designing the conflict policy explicitly, field by field, is one of the clearest markers of an integration built by engineers rather than assembled from a template.

Mapping and deduplication: the unglamorous half of the work

Before any record can sync, the two systems have to agree on what a record is. This is data mapping, and it is where most of the real effort goes.

Field mapping translates one schema into another: a HubSpot contact's lifecycle stage into your other system's customer status, a multi-line address into discrete address fields, a picklist value into the equivalent option on the far side. Mismatched data types, different date formats and enumerations that do not line up all have to be handled, not assumed away.

Deduplication answers a harder question: is this the same record we already have? If both systems key on email and someone uses a different address, you create a duplicate. If you key on an external ID that one side does not store, you cannot match at all. Robust syncs maintain a mapping table of cross-system identifiers so that record A in HubSpot is permanently tied to record B elsewhere, regardless of what changes on either side. Getting this wrong is how a sync turns a clean database into thousands of near-duplicate contacts. Our data engineering work usually starts here, because a sync is only as trustworthy as the matching logic underneath it.

Reliability: what happens when something breaks

Networks drop. APIs rate-limit. Systems go down for maintenance. A production-grade sync is defined less by its happy path than by how it behaves when the happy path fails. The features that matter:

• Retries with back-off. A failed write is retried on a sensible schedule rather than dropped or hammered.
• Idempotency. Replaying the same event twice does not create two records or double a value. Each event can be safely processed more than once.
• Dead-letter handling. Events that cannot be processed are captured for inspection instead of vanishing.
• Ordering guarantees. A "created" event is processed before the "updated" event that follows it, even if they arrive out of order.
• Monitoring and alerting. Someone is told when the sync falls behind, before a customer notices.

Off-the-shelf connectors and no-code automations rarely expose these controls. They work until they do not, and when they fail they tend to fail silently. For a back-office task that may be acceptable. For data a customer is reading off a screen, it is not.

Why this is the custom integration wedge

Native connectors, HubSpot's Data Sync and iPaaS tools such as Zapier or Make all have a place, and the pillar guide explains exactly where each fits. They cover a lot of ground for standard objects and modest volumes. Where they consistently fall short is precisely the territory described above: true real-time two-way flow, explicit per-field conflict handling, deduplication against custom or ERP objects, and reliability you can monitor. That is the gap custom, real-code integration is built to close. SpotDev holds HubSpot's Custom Integration Accreditation and has delivered integrations across more than 300 projects, including against undocumented, legacy and firewalled systems with no friendly API.

If you are weighing up whether a connector will hold up under the load your portal or dashboard is about to put on it, talk to us about a custom HubSpot integration built to sync in real time, both ways, reliably.