Bullhorn HubSpot Integration in the UK: A Practical Guide

TL;DR: The native HubSpot Marketplace connector syncs Candidates, Companies, Opportunities and Appointments, but not Placements, Job Orders, Tearsheets or Submissions, which is where most of the operationally useful Bullhorn data sits. Agencies with temp or contract desks almost always end up on middleware instead, at roughly £3,000 to £8,000, with a custom API build at £10,000 to £25,000 where the Bullhorn configuration is bespoke. The decisions that determine whether the integration works are made before any field mapping: deduplicate Bullhorn first, name one master system of record for every synced field, and decide which candidate data must never reach a marketing CRM.

Why do UK recruitment agencies connect Bullhorn and HubSpot?

Bullhorn owns the delivery side of a recruitment business. It is built around candidates, placements, job orders, and submissions - the workflow from vacancy to filled seat. HubSpot owns the BD side. It is built around pipeline, deal stages, and client relationships. By default, these two systems share nothing, which means your consultants are either duplicating data entry across both platforms or operating blind to what is happening on the other side of the business.

For a step-by-step comparison of the three ways to connect the two systems, see how to connect Bullhorn to HubSpot.

The practical consequence of that gap is straightforward. A BD consultant marks a client as warm in HubSpot, books a meeting, agrees a briefing call, and progresses a deal through the pipeline. None of that is visible to the delivery team in Bullhorn when they start sourcing candidates for that same client. They have no context on what was promised, what the relationship stage is, or what margin expectation sits against the job. That context gap costs time and occasionally costs client relationships.

UK staffing agencies also have a structural complexity that makes a generic CRM integration harder than it looks. Temp, contract, and perm desks have genuinely different data requirements. A temp desk needs placement dates, pay rates, margin, and timesheet status - none of which belong in HubSpot. A perm desk is closer to a standard sales pipeline and maps more naturally. Contract desks sit somewhere in between, often with IR35 status and engagement type considerations layered on top. A single integration configuration rarely covers all three without compromise.

The revenue leakage argument is worth taking seriously too. When BD activity lives in HubSpot and placement history lives in Bullhorn, no one has a complete picture of client value. Renewal opportunities, cross-sell moments, and warm outreach triggers go unactioned because the data that would surface them is split across two systems with no connection between them. The integration solves a real problem - but only when it is built correctly, with the right objects syncing in the right direction, and the data governance in place to support it.

What does the native HubSpot-Bullhorn connector actually do?

The native connector, available on the HubSpot Marketplace, handles four object types: Candidates to Contacts, Companies to Companies, Opportunities to Deals, and Appointments. Two-way sync is available, and there is a historical sync option that pulls existing records across on initial setup. For an agency starting from a relatively clean data position with a simple workflow, that initial historical pull is genuinely useful - it means you are not starting HubSpot with an empty contact database.

Worth knowing before you commit to this route: the connector sits at 2.1 out of 5 stars from 9 reviews on the HubSpot Marketplace. That is not a rounding error or a cluster of unreasonable users. Nine reviews is a small sample, but a 2.1 average is a signal worth taking seriously before you spend implementation time on this path.

The more significant limitation is what the connector does not cover. Placements, Tearsheets, Job Orders, and Submissions are not part of the standard sync. Those four objects contain most of the operationally useful data in Bullhorn - placement dates, bill rates, pay rates, job status, submission outcomes. Agencies that need placement data visible in HubSpot will find the native connector reaches its ceiling quickly and will be back to square one within a few months of go-live.

The two-way sync also creates a problem that sounds manageable until you encounter it in practice. If a contact's job title is updated in HubSpot after a BD call, and the same field is updated differently in Bullhorn by a resourcer who found a LinkedIn profile in the same sync window, the connector does not have a reliable, configurable rule for which value wins. This is a design flaw in the connector, not an edge case in your configuration. The conflict resolution logic is opaque, and the outcome is unpredictable.

The default field mappings are built against Bullhorn's standard field structure. Most agencies running Bullhorn for more than 18 months will have customised their instance - custom fields, renamed fields, fields repurposed from their original design to fit how that agency actually works. Those defaults will not survive contact with a real agency's configuration without manual adjustment, and the connector's UI for managing field mappings is limited.

How do Bullhorn objects map onto HubSpot objects?

Candidates map to HubSpot Contacts and Companies map to Companies, and those two are clean enough that the native connector handles them. Everything else needs a decision. Placements, Job Orders, Tearsheets and Submissions have no honest equivalent in HubSpot's standard object model, so each one either becomes a HubSpot Custom Object, which requires Sales Hub Enterprise or Service Hub Enterprise, or it does not sync at all.

Bullhorn's data model is built around recruitment workflow. The central objects are Candidates, Placements, Job Orders, Tearsheets, and Submissions. HubSpot's data model is built around sales workflow - Contacts, Companies, Deals, and Pipelines. These two models reflect genuinely different ways of thinking about relationships and process, and mapping one onto the other requires deliberate decisions at every step.

The easy mappings are Candidate to Contact and Company to Company. These are relatively clean, and the native connector handles them adequately when the underlying data is in good shape. Get the deduplication right before the sync runs and these two mappings cause minimal problems.

Placements are harder. A Placement in Bullhorn has no direct equivalent in HubSpot's standard object model. The closest approximation is a Deal, but a Deal in HubSpot represents an opportunity in progress - a Placement represents a completed outcome. If you use Deals to represent Placements, your HubSpot pipeline fills up with closed-won deals that are not won business in the BD sense. Your pipeline reporting becomes unreliable, your forecast metrics mean nothing, and your sales team loses confidence in the tool within a month. The alternative is HubSpot's Custom Objects, which let you create a Placement object with its own properties and associations. That is the right structural decision, but Custom Objects require HubSpot Sales Hub Enterprise or Service Hub Enterprise - an additional cost that needs to factor into the integration business case from the start.

Job Orders present a different problem. A Job Order could reasonably be a Deal in HubSpot, but Deal stages in HubSpot are designed for linear sales progression. Recruitment job order workflows are non-linear - a job can go from active to on hold to filled to re-opened, sometimes multiple times. Standard Deal stage logic does not handle re-opening well, and the reporting assumptions baked into HubSpot's deal analytics break when a deal moves backwards through stages repeatedly.

The person who exists in both systems

The most common and most damaging mapping problem in any Bullhorn HubSpot integration UK implementation is the contact who appears in both systems in different roles. A placed contractor who also has procurement or line management responsibility at their employer exists as a Candidate in Bullhorn and as a client Contact in HubSpot. This is not an unusual edge case in recruitment - it is a fairly common situation, particularly on contract desks.

When the sync runs, it will try to match these records based on email address. Depending on how the matching logic is configured, it either creates a duplicate - one candidate record and one contact record with the same email - or it merges them, potentially overwriting client contact data with candidate data or vice versa. Either outcome is damaging. A merged record that pulls a candidate's IR35 status or pay rate into a client contact record is a data governance failure. A duplicate that sends the same person two different email sequences is an embarrassment.

You need a clear deduplication strategy and a defined rule for which system's record takes priority before the sync is configured, not after it has run and the damage is already done. The mapping document - a table of Bullhorn objects and fields against their HubSpot equivalents, with explicit decisions about what syncs, what does not, and which system wins on conflict - is not optional on any implementation I would sign off on.

Native connector, middleware or custom API: which should you choose?

Most UK agencies with a real integration requirement end up on middleware. The native connector only holds up for small, perm-focused agencies with clean data and no need to see placement information in HubSpot, and a custom API build is only justified when the Bullhorn instance is heavily customised or the placement reporting requirements are specific enough that middleware cannot express them. Workflow complexity and data volume decide this, not the starting price.

There are three realistic routes for connecting Bullhorn and HubSpot, and the right choice depends on workflow complexity and data volume, not on which option is cheapest to start with.

Option 1: native connector

The native HubSpot Marketplace connector has no additional per-record cost beyond what you are already paying for both platforms. A basic setup with sensible field mappings can be configured in 2 to 3 days. It covers standard objects only, has poor conflict resolution handling, and its rating history suggests real-world reliability issues.

It is suited to very small agencies - under 10 consultants - with a simple workflow, minimal temp or contract exposure, and clean existing data. If you are a perm-only agency with a straightforward BD process and you are not looking to sync placement data, it is a reasonable starting point. If you have complex placement data requirements, custom Bullhorn fields, or the dual-system contact problem described above, it will not hold up.

Option 2: middleware

Middleware tools - Zapier, Make, and n8n - offer considerably more flexibility than the native connector. They can handle custom objects, conditional logic (for example, only sync a candidate record if they have an active placement and are marked as placeable), non-standard field mappings, and transformation steps that convert free-text values to controlled dropdown options. This is where the majority of agencies with real integration requirements end up.

n8n is particularly well-suited to this use case. It can run on self-hosted infrastructure, which is relevant for UK agencies with specific data residency requirements. It supports complex branching logic, has a genuine API node for both Bullhorn and HubSpot, and is cheaper at scale than Zapier for high-volume syncs. Rough build cost for a middleware integration: £3,000 to £8,000 depending on the number of objects, the complexity of the conflict resolution logic, and how clean the data is going in.

Worth flagging here: middleware built badly is often worse than no integration at all. A Zapier workflow that triggers on every record update rather than on meaningful changes, has no error handling, and produces no logs will propagate bad data at speed. The build quality matters as much as the tool choice.

Option 3: custom API

Bullhorn exposes a REST API that is reasonably well-documented. HubSpot's API is mature and reliable. A custom-built integration can handle any object, any field, and any conflict resolution logic you define. It is the highest-control option and the highest-cost one.

Rough cost: £10,000 to £25,000 or more depending on scope, with ongoing maintenance overhead that needs to be factored in. Not the right choice for most agencies, but the right choice for those with bespoke Bullhorn configurations, complex placement reporting requirements, or specific data processing constraints that middleware cannot satisfy.

The important scoping decision: starting with the native connector and migrating to middleware when it breaks is a more expensive path than getting the scoping right at the start. The discovery work is the same either way - you are just paying for it twice if you skip it on the first pass.

What are the GDPR implications of syncing Bullhorn and HubSpot?

Syncing candidate data into HubSpot creates three specific GDPR obligations for a UK agency. Deletion has to propagate, so a right to erasure request raised in Bullhorn must remove the record from HubSpot too. Lawful basis has to be translated rather than assumed, because candidate data processed under legitimate interests in Bullhorn does not arrive in HubSpot with a valid marketing subscription status. And special category data, such as health information, DBS results and right-to-work references, should not be in the sync at all.

Any cross-system sync involving candidate data has compliance implications that need to be addressed before the integration goes live, not patched afterwards.

The core problem is that consent records, lawful basis documentation, and data subject rights requests need to be honoured in both systems. A candidate who submits a right to erasure request in Bullhorn needs that deletion to propagate to HubSpot. A sync that moves personal data between systems but does not move deletion events is a compliance gap, regardless of how well the field mappings are configured. You need a documented process for handling data subject rights requests that covers both platforms, and the integration should support that process rather than complicate it.

The lawful basis alignment question is specific to recruitment. Agencies typically process candidate data under legitimate interests or contractual necessity, not consent. HubSpot's marketing tools are built around consent-based contact management - subscription statuses, opt-in tracking, suppression lists. When candidate records land in HubSpot without explicit subscription configuration, those candidates can end up receiving marketing emails they never agreed to. The lawful basis under which data was collected in Bullhorn does not automatically translate into appropriate HubSpot subscription status. You need to configure HubSpot subscription types before the sync runs and define which incoming records get suppressed from marketing communications by default.

Some candidate data has no place in a marketing CRM and should not sync to HubSpot at all. Health information, DBS check results, right-to-work documentation references, biometric data, and IR35 status classifications all fall into this category. Syncing a contractor's IR35 determination into HubSpot creates unnecessary data exposure and serves no BD or marketing purpose. A reasonable rule: if it would not appear on a business card or come up in a BD meeting agenda, it probably should not be in HubSpot.

Data residency is worth checking rather than assuming. HubSpot stores data on AWS infrastructure, with EU data residency available on certain plans. For UK agencies with sector-specific compliance requirements - healthcare staffing, financial services, defence - it is worth confirming where synced data sits and whether that creates a conflict with existing Data Processing Agreements. It is rarely a blocker, but it needs to be a deliberate decision.

Before any field mapping is configured, document which fields will flow in each direction, what the lawful basis is for processing that data in the destination system, and how deletion events will propagate. That documentation does not need to be lengthy, but it does need to exist.

Common Bullhorn-HubSpot integration mistakes and how to avoid them

Enabling the sync before deduplicating Bullhorn records. Most agencies running Bullhorn for more than 3 years have duplicate candidate records. When the sync runs, those duplicates propagate into HubSpot. If two Bullhorn records share an email address, HubSpot will attempt to merge them - often incorrectly, combining unrelated candidate histories into a single contact. If they do not share an email, HubSpot creates two separate contacts. Run a deduplication exercise in Bullhorn first. It is time-consuming, but it is significantly less time-consuming than cleaning a contaminated HubSpot database after go-live.

Not defining a master system of record for each synced field. If both systems can write to the same field, you will get conflicts. The most common version is job title - updated in HubSpot after a BD call, then overwritten by a Bullhorn sync pulling the old value. Every synced field needs a documented owner: which system wrote it last, and which system wins if both have updated it within the same sync window. "Both can update it" is not a valid answer and will produce unpredictable results.

Mapping fields that do not share a controlled vocabulary. A free-text Sector field in Bullhorn syncing to a dropdown Sector property in HubSpot will either throw an error or create a blank value. This is extremely common because Bullhorn instances often carry free-text fields that were never properly governed. The fix is either to clean the Bullhorn data to match HubSpot's dropdown options before the sync runs, or to add a transformation step in the middleware that maps known values to valid dropdown options and flags unknowns for manual review rather than silently dropping them.

Testing only on clean test data. Test data does not surface conflict behaviour. Before going live, take a sample of 50 to 100 real records that you know exist in both systems and run the sync against them. Watch what happens field by field. That is where the edge cases appear - records with unusual characters in name fields, contacts with multiple associated companies, candidates with blank email addresses that the matching logic cannot resolve.

Automating a broken process. If your BD team's approach to recording client activity in HubSpot is inconsistent, and your consultants' approach to updating candidate records in Bullhorn is inconsistent, connecting the two systems makes both sets of inconsistency more visible and more damaging. The integration amplifies whatever process quality exists underneath it. Define what good data looks like in both systems and reach that baseline before the sync is switched on.

What a realistic implementation looks like

Discovery

Discovery means mapping the current data flows between the two systems - including the manual ones. Spreadsheets, copy-paste habits, shared inboxes, and WhatsApp messages that contain client information which never makes it into either system. These are the real data flows. Identify which objects genuinely need to sync versus which objects people assume need to sync because they have not thought through the implications. Define the master system of record for each field you plan to sync, and document the deduplication rules before any configuration begins.

This phase typically takes 1 to 2 days. It is where most of the real decisions get made, and skipping it is how you end up rebuilding the integration 6 months later when the edge cases you did not anticipate start corrupting records at scale.

Build

Build covers configuring the connector or middleware, writing conflict resolution logic, building transformation steps for any field type mismatches, and testing on a subset of real records. For a native connector setup with basic field mapping and clean data, this is 2 to 3 days of work. For a middleware build with custom objects, placement sync logic, dual-identity contact handling, and proper error logging, it is more likely 5 to 10 days depending on the complexity of the Bullhorn configuration and the state of the data going in.

Error handling and logging are not optional extras to be added later. A sync that fails silently - dropping records or skipping updates without logging what happened - is harder to diagnose than one that was never built at all. Every integration I build includes a logging layer and a defined alert process for sync failures.

Go-live

Data cleaning in both systems happens before the sync is switched on, not after. Brief the teams who will be affected on what will sync and what will not - specifically, brief them on what will change in their day-to-day workflow. Set up monitoring for sync errors in the first 30 days. HubSpot logs sync errors but does not alert on them by default, so you need a process for checking those logs regularly in the first month. Most post-launch issues surface in the first two weeks and are usually field mapping edge cases or records that match on something other than email address.

The integration is only as useful as the data going into it. A well-built sync on clean data gives you a genuinely useful combined view of client and candidate activity across both platforms. The same sync on poorly governed data gives you two systems of record that are both wrong, and it makes them wrong faster than they would have been on their own.

If you are at the stage of scoping a Bullhorn HubSpot integration UK project and want to work through the object mapping decisions, GDPR implications, and connector options with someone who has built these integrations for UK recruitment agencies, a RevOps audit is the right starting point - it covers both systems, identifies where the data governance gaps are, and produces a scoped recommendation before any build work begins.