Salesforce and HubSpot both want to be the source of truth for the same customer record, and when the two systems fall out of step, sales and marketing end up working from different versions of reality.
Most businesses that run both platforms did not plan it that way. Sales standardizes on Salesforce for pipeline management, marketing builds campaigns and forms in HubSpot, and within a few months both systems are holding overlapping records of the same contacts and companies. HubSpot's own documentation confirms that its Salesforce integration is built to synchronize contacts, companies, deals, activities, and other supported data between the two platforms, which is exactly the kind of connective tissue that keeps sales and marketing working from the same information.[1]
A working sync between the two systems generally supports:
There are three common approaches to connecting the platforms, and it is worth understanding all three before assuming you need the most complex one.
These three options trade off against each other on complexity, customization, data volume, sync frequency, the amount of business logic they can express, ongoing maintenance, and cost. Readers evaluating custom middleware should understand this tradeoff clearly, because the native integration is often enough on its own, and a heavier build is only worth it when the standard connector genuinely cannot do what the business needs.
HubSpot supports configurable field mappings, sync directions, and syncing of custom objects out of the box.[4][5] But mature Salesforce orgs often carry years of process refinement in the form of validation rules, required fields, and deeply embedded custom objects, and an integration that does not respect that structure can generate sync errors or incomplete records.[6] Custom middleware tends to make sense when a business runs into:
A custom middleware setup follows a straightforward architecture: Salesforce feeds records into the middleware, the middleware stores and processes them, and then it pushes the finished records into HubSpot.
The reason middleware is worth the extra build effort is that it acts as a control layer, not just a pipe. Data does not move directly from one CRM to the other; it passes through a system you own, where it can be validated, transformed, filtered, and logged before it ever reaches HubSpot.
Authentication for server-to-server integrations typically uses the OAuth 2.0 JWT bearer flow rather than username-password authentication, which Salesforce has deprecated for production use.[10] Once connected, records are retrieved with SOQL queries filtered on Last Modified Date rather than pulling the entire object every run, which is the single biggest lever for staying inside Salesforce's API limits.[8] Governor limits apply per transaction rather than per API call, so a single request that triggers heavy Apex logic can consume far more of your budget than the raw call count suggests, which is worth accounting for when you size your polling interval.[9]
Incoming records land in a local MySQL table before anything is sent to HubSpot. This gives the middleware a place to normalize inconsistent formatting, track which records have already been synced so they are not reprocessed unnecessarily, and log errors in a way that survives a failed run instead of silently dropping records.
Field mapping needs to account for standard fields, custom fields, differences in data types between the two platforms, and which HubSpot properties are required before a record can be created. HubSpot's own field mapping tools let you pair a HubSpot property with a specific Salesforce field for contacts, companies, and deals, which is a useful reference point even when you are building the mapping logic yourself.[4]
The final step covers creating new records, updating existing ones, matching against records that already exist in HubSpot, and handling whatever comes back in the API response. HubSpot's batch endpoints let you create, update, or read multiple records in a single call, which is the standard way to keep call volume down during a sync run rather than sending one request per record.[12] When a request does get rate-limited, the standard pattern is to read the Retry-After header and back off with exponential delay rather than retrying immediately.[13]
Salesforce Accounts map to HubSpot Companies in HubSpot's own native integration, so it is a well-established pairing to model middleware logic on.[3] A reliable sync in this direction needs to:
Contact syncing is usually the highest-volume part of the integration. Salesforce leads and contacts both resolve down to HubSpot contacts, with accounts syncing to companies based on matching rules such as company domain.[15] Email address remains the primary matching mechanism HubSpot uses to reconcile Salesforce leads and contacts against existing HubSpot records, and contacts generally will not sync at all without one.[2] Custom middleware needs to replicate this same discipline: match on email first, create a new contact only when no match exists, update existing contacts rather than duplicating them, and keep the contact-to-company relationship intact on every write.
Activity and event data is where a lot of native integrations fall short, because Salesforce Events do not map cleanly onto a single HubSpot object the way Accounts and Contacts do. A custom sync for this data typically needs to retrieve Salesforce Events filtered by modification date, transform the event data into whatever structure the destination content type expects in HubSpot, send the transformed record through the API, and account for recurring or subsequently updated events so activity history stays accurate for reporting.
Instead of retrieving every Salesforce record on every run, middleware should check which records changed since the last successful sync. Delta queries filtered on Last Modified Date can reduce API consumption by more than 90 percent in mature orgs, where most records simply have not changed since the previous run.[7] This pattern, often called a scheduled read, polls Salesforce on a configurable interval such as every 5, 10, or 30 minutes and pulls only the records that changed in that window, using LastModifiedDate together with paginated SOQL queries to make sure nothing with an identical timestamp gets skipped.[11][9] The tradeoff is that scheduled reads are predictable, easy to throttle, and easy to debug, but they do consume API quota on every poll whether or not anything actually changed.[11]
A well-built incremental sync should also be able to recover cleanly from a failed run, picking back up from the last confirmed checkpoint instead of re-pulling everything or silently missing records.
Duplicate records are one of the most common complaints businesses raise about CRM integrations, and preventing them has to be designed into the middleware rather than cleaned up after the fact. That means:
This is one of the strongest commercial-intent reasons businesses look at custom middleware in the first place, because data quality problems compound quietly until reporting stops being trustworthy.
Every reliable sync starts with a documented field mapping, not a mapping that only exists in code. An integration mapping document should cover which HubSpot properties map to which Salesforce fields for contacts, companies, deals, and activities, whether each field syncs one way or two ways, and which system wins when both sides have a value.[14] Also plan for:
There is no single correct sync frequency. Scheduled sync intervals commonly run every 5, 10, or 30 minutes depending on how time-sensitive the data is and how much API quota is available to spend on polling.[11] The right frequency for a given business depends on:
Tighter intervals mean fresher data but higher API usage, and looser intervals conserve quota at the cost of lag. Most businesses land somewhere between 15 minutes and hourly for standard objects, with real-time or near-real-time reserved for the specific fields that actually justify it.
Ongoing sync and historical data migration are two different problems, and they should be treated that way. Historical migration typically covers existing Accounts moving into Companies, existing Contacts moving into Contacts, and existing Events moving into the appropriate HubSpot records, all processed in batch rather than through the same incremental job that handles day-to-day sync. For large historical loads, the Bulk API is built for exactly this kind of volume and can move millions of records far more efficiently than looping through single-record calls.[10] A historical migration should also include its own data validation, duplicate prevention pass, and post-migration QA before the ongoing incremental sync takes over.
A sync that works once is not the same as a sync that works reliably. Before it goes live, and on an ongoing basis afterward, testing and monitoring should cover:
It is worth being direct about this: custom middleware is not automatically the better option. It is the right option when the native integration cannot express what the business actually needs.
| Requirement | Native Integration | Custom Middleware |
|---|---|---|
| Standard contact sync | Yes | Yes |
| Standard company sync | Yes | Yes |
| Custom business logic | Limited | Yes |
| Custom data transformation | Limited | Yes |
| Custom sync schedules | Limited | Yes |
| Historical data processing | Depends | Yes |
| Complex associations | Depends | Yes |
| Custom workflows | Limited | Yes |
| Full control over API logic | No | Yes |
Custom middleware tends to make the most sense when a business needs some combination of:
Need to connect Salesforce and HubSpot around your specific business processes? Computan can help design and implement custom CRM integrations that connect your systems, automate data synchronization, and accommodate your unique business logic.
Native integrations are suitable for a large share of standard use cases, and there is no reason to build custom middleware just because it is possible. Custom middleware earns its place when business requirements go beyond standard synchronization: non-standard objects, strict source-of-truth rules, conditional logic, or historical data that needs its own migration path. A well-designed middleware layer gives you real control over mapping, scheduling, transformation, validation, and error handling. The goal was never simply to move data between two CRMs. It is to build a reliable flow of usable business data that both teams can trust.
Computan is a Canadian digital technology company serving businesses across Canada, the United States, the United Kingdom, Australia, and other markets worldwide. Our team helps businesses connect and optimize their technology ecosystems, including CRM integrations, HubSpot development, Salesforce integrations, custom middleware, and marketing technology solutions.
Sources:
Do I need custom middleware to connect Salesforce and HubSpot?
Not always. HubSpot's native Salesforce integration handles standard contact, company, deal, and activity syncing for most businesses. Custom middleware is worth building when you need custom business logic, non-standard objects, conditional sync rules, or Salesforce enforced as a strict source of truth.
What does a custom Salesforce to HubSpot middleware actually look like?
Typically a Laravel application backed by a MySQL database, sitting between the Salesforce API and the HubSpot API. It pulls changed Salesforce records, stores and transforms them locally, then pushes the finished records to HubSpot on a defined schedule.
How does incremental sync work between Salesforce and HubSpot?
Instead of pulling every record on every run, the middleware queries Salesforce for records modified since the last successful sync using the Last Modified Date field. This keeps API usage low and sync windows short, even on large datasets.
How do you prevent duplicate records when syncing Salesforce and HubSpot?
By matching on unique identifiers before writing any record, typically email for contacts and domain for companies, and by storing the Salesforce ID alongside the HubSpot record ID so future syncs can match reliably instead of creating a second record.
Can Salesforce Events sync to HubSpot?
Yes, though Events do not map to a single HubSpot object as cleanly as Accounts or Contacts do. A custom sync typically retrieves events by modification date, transforms them into the structure the destination HubSpot content type expects, and accounts for recurring or updated events.
How often should Salesforce and HubSpot data sync?
Most scheduled syncs run somewhere between every 10 minutes and every hour, depending on data volume, available API quota, and how quickly sales and marketing actually need updated information to act on it.
Is historical data migration different from ongoing sync?
Yes. Historical migration moves existing Accounts, Contacts, and Events into HubSpot in batch, usually through the Bulk API, and includes its own validation and QA pass. Ongoing sync then takes over with incremental, Last Modified Date-based updates.