How to Connect Bullhorn to HubSpot: 3 Methods Compared

Which Integration Method Is Right for You

Three routes exist for connecting Bullhorn to HubSpot: native HubSpot Data Sync, Zapier, and a custom REST API integration. If you want a quick answer before reading further - most UK recruitment agencies should start with Method 1, the native Data Sync. It handles the core use case (Candidates to Contacts, Companies, Appointments) without requiring developer resource, and it covers roughly 80% of straightforward setups well.

Native Data Sync is the right starting point if you want standard object sync with low maintenance overhead and no code. It's the lowest-cost option, it's managed within HubSpot, and for most agencies it does enough. The limitations only start to bite when you need Jobs data in HubSpot, complex field logic, or bidirectional updates on custom objects.

Zapier suits lightweight, event-triggered flows - one or two specific automations where you don't need a full sync. It's a reasonable choice for early-stage setups or proof-of-concept work. The problem is that people often reach for Zapier because it feels accessible, not because it's the right fit. If you find yourself building five or six Zaps to replicate what a proper integration would handle, you're on the wrong route and the task-based pricing will catch up with you.

Custom REST API is the right call when you have bidirectional requirements that go beyond what the native sync supports, custom objects, or logic-heavy workflows - for example, a Job moving to a certain status in Bullhorn triggering a Deal stage update in HubSpot. This requires a developer or a specialist. Build time runs from 3 days for a scoped sync to 10 days or more for a full implementation. Ongoing maintenance is a real cost that doesn't go away.

Prerequisites Before You Start

Missing prerequisites is the most common reason integrations fail at step one. Not a configuration error - just incomplete setup before anyone touches the connection. Check these before you start, not halfway through.

Native Data Sync

On the HubSpot side, you need Marketing Hub Starter or above to access the Data Sync app. However, if you want to map custom Bullhorn fields to custom HubSpot properties, you need Data Hub Starter (previously Operations Hub Starter) as a minimum. HubSpot's UI doesn't surface a clear error if you're on the wrong plan - it simply won't show you the custom field mapping options. Worth checking your plan before you get into configuration.

On the Bullhorn side, API access is only available on the Team plan and above. Starter and Essentials plans do not expose the API. The integration will fail to authenticate if API access isn't enabled on your Bullhorn account - confirm your tier with your Bullhorn account manager before starting.

Zapier

Bullhorn's Zapier integration requires API access on the Bullhorn side - same tier requirement as above. One thing to be aware of: some Zapier templates appear available in the Zapier interface even if your Bullhorn plan doesn't support them. You won't find out until the authentication step fails. On the Zapier side, you need a Professional plan or above for multi-step Zaps - the free plan won't get you far here.

Custom REST API

For Bullhorn, you'll need your corp ID, username, API key, and base URL. These are found in Bullhorn under Settings > API Access. Some Bullhorn instances have API credentials managed by the account team rather than accessible to end users directly - if you don't see the API Access menu, raise it with your Bullhorn account manager rather than assuming it doesn't exist.

For HubSpot, create a Private App in Settings > Integrations > Private Apps. Scope the token to only the objects you need - contacts, companies, deals, custom objects. Do not use a legacy API key. HubSpot deprecated those in November 2022 and they no longer work for new integrations.

Method 1: Native HubSpot Data Sync

Step-by-step setup

This is the recommended starting point for most agencies looking at how to connect Bullhorn to HubSpot without involving a developer.

• In HubSpot, go to the App Marketplace via the Marketplace icon in the top navigation. Search for "Bullhorn" and install the Bullhorn Data Sync app.

• You'll be prompted to authenticate with your Bullhorn credentials. You need your corp ID and username from the prerequisites checklist. Complete the OAuth flow - if it fails here, API access on your Bullhorn account is either not enabled or the credentials are wrong.

• Once authenticated, you'll see the object sync configuration screen. The most common starting point is Candidates to Contacts. You can also configure sync for Companies and Appointments. Each object has its own sync direction setting - one-way or two-way - configured separately.

• Review the default field mappings before activating. HubSpot pre-populates standard mappings for first name, last name, email, and phone. These are fine for basic setups, but if your Bullhorn instance uses custom fields you'll need to add those manually.

• Set filter rules before activating a full sync. Rather than pulling every Candidate in your database into HubSpot from day one, filter by status - for example, only sync active Candidates. A large unfiltered sync is harder to clean up than a scoped one.

The Bullhorn Jobs problem

Jobs in Bullhorn have no direct equivalent in HubSpot's standard data model, and the native sync doesn't handle them. If you need Jobs data in HubSpot, the workaround is to create a Custom Object in HubSpot and map Job fields to it manually. Custom Objects require Operations Hub Professional or above, so there's a plan cost attached. For most agencies this isn't something you need to solve on day one - but if Jobs-to-Deals logic is part of your roadmap, plan for it before you're mid-implementation and realise the plan upgrade wasn't budgeted.

Field mapping and plan limitations

Standard field mappings work on lower plans. Custom field mappings - where you're mapping a non-standard Bullhorn field to a custom HubSpot property - require Data Hub Starter as a minimum. If you're on a lower plan and try to configure a custom mapping, the option won't appear. There's no error. You'll just hit a wall and not immediately understand why.

The initial sync can take several hours if you have a large Bullhorn database. Check the sync status in HubSpot's Data Sync settings rather than assuming it's broken if nothing appears in the first hour. Large databases with 50,000+ candidate records can take the better part of a day on first sync.

Method 2: Zapier

Setting up the Zap

Create a new Zap and select Bullhorn as the trigger app. The most common starting flow is "New Candidate" in Bullhorn triggering "Create or Update Contact" in HubSpot. Connect your Bullhorn account using the API credentials from the prerequisites. Connect HubSpot via OAuth - sign in through HubSpot's auth screen. Both connections get tested during setup, with Zapier pulling a sample record to confirm the trigger is working.

In the Zap editor, map Bullhorn candidate fields to HubSpot contact properties. You're working with whatever Zapier exposes from the Bullhorn trigger payload - and that's a known limitation. Custom fields, particularly those added to your Bullhorn instance, may not appear in the payload at all. If a field you need isn't there, Zapier is the wrong tool for this particular mapping.

Before activating, use Zapier's Test step. It will create a real record in HubSpot using your sample data, so use a test contact rather than a live candidate. Check the record appears correctly in HubSpot - field values, formatting, any conditional logic you've set up - before switching the Zap on.

Where Zapier falls short

Zapier is trigger-based only. It fires when something happens in Bullhorn - it doesn't perform a retroactive sync of existing records. If you have 10,000 existing Candidates in Bullhorn and you want them in HubSpot, Zapier won't help with that.

Each Zap runs in one direction. Bidirectional sync means building at least two Zaps, and each distinct update scenario - new candidate, updated email, status change - potentially needs its own Zap. Zapier's task-based pricing means this adds up quickly, and a tangle of overlapping Zaps becomes genuinely difficult to maintain and debug when something goes wrong.

Zapier works well for specific, named event flows: new Candidate creates a HubSpot Contact, new Appointment creates a HubSpot Task. If you're trying to keep two systems in continuous sync or handle complex update logic, you're outside what Zapier does well.

Method 3: Custom REST API Integration

Bullhorn REST API authentication

Bullhorn uses OAuth 2.0 with session tokens. The authentication flow runs in sequence: authenticate with your API credentials to get an authorisation code, exchange that for an access token and session token, then use the session token in all subsequent API calls. Session tokens expire after several hours of inactivity - the exact timeout depends on your Bullhorn configuration. Handling token refresh in your integration logic is not optional; it's a required part of the build. This is the most common point of failure for people building a Bullhorn integration for the first time. The integration works fine in testing, then silently stops producing results in production when the session token expires and there's no refresh mechanism.

HubSpot API setup

Create a Private App in HubSpot under Settings > Integrations > Private Apps. Scope the token to the specific objects your integration needs - contacts, companies, deals, custom objects as applicable. Don't over-scope; keep permissions tight. HubSpot's API is REST/JSON and well-documented. The rate limit is 100 requests per 10 seconds on standard plans, which is generous enough for most integration workloads. It's the easier side of the two to work with.

Middleware vs. direct build

There are two architectural options for a custom integration.

Middleware - tools like n8n, which is what I use for most of this work - gives you visual workflow logic, built-in error handling, retry mechanisms, and execution logs. The authentication flows for both Bullhorn and HubSpot are manageable within n8n, and the lower code overhead compared to a direct build makes iteration faster. n8n can be self-hosted or run via their cloud offering, and the cost is significantly lower than Zapier at scale.

Direct integration via custom code gives you more control and suits performance-sensitive or highly specific use cases. The trade-off is that you own everything: rate limit handling, retry logic, error logging, credential refresh, and ongoing maintenance as both APIs evolve. It's the right call when you have a very specific requirement that middleware can't handle cleanly - not as a default choice.

What it actually takes to build

The main technical challenge is that Bullhorn's ATS data model and HubSpot's CRM objects don't map one-to-one. Candidates, Jobs, Placements, Submissions - none of these have direct HubSpot counterparts. You're either mapping them to existing HubSpot objects in ways that stretch their intended meaning, or building Custom Objects. Expect the data modelling conversation to take as long as the actual build, sometimes longer.

For a basic bidirectional Candidate-Contact sync with a handful of custom fields, budget 2-3 days. A full integration covering Jobs, Placements, and deal stage logic is 7-10 days minimum. Bullhorn API changes, token expiry edge cases, and data model drift between the two systems are ongoing maintenance realities, not one-off problems.

Post-Connection Hygiene

Most integration problems surface in the first 48 hours of a live sync. Treat that window as an active monitoring period.

Deduplication before you activate. If you already have Contacts in HubSpot and Candidates in Bullhorn sharing email addresses, the sync will attempt to match on email by default. Understand what the sync does when a match isn't found - does it create a new record, skip the record, or throw an error? Set this behaviour explicitly before going live rather than discovering it through a wave of duplicate contacts appearing in HubSpot.

Use HubSpot's sync health dashboard. In Data Sync settings, you can see every record that failed to sync with a reason code. Check this daily for the first week. Common failure reasons include: missing required field (a Bullhorn candidate with no email address is a very frequent one in recruitment databases), object mismatch, and plan limitations blocking a field mapping. Run a Bullhorn report of candidates without email addresses before activating the sync - it'll give you a cleaner first pass.

Audit a sample of synced records manually. Pull 10-20 records after the initial sync completes and check that fields are populated correctly in HubSpot. Some fields sync without throwing an error but arrive with the wrong value or format - particularly date fields and picklist values where the options between the two systems don't align exactly.

Validate sync direction explicitly. If you've configured a two-way sync, test an update in each system and verify it appears in the other. Agree which system owns each field and make sure HubSpot isn't overwriting data that Bullhorn owns - particularly candidate status fields where Bullhorn should always be the source of truth.

Common Failure Points and How to Avoid Them

Sync conflicts from simultaneous edits. The native Data Sync uses a last-write-wins approach. If a recruiter updates a candidate's phone number in Bullhorn at the same moment a HubSpot workflow updates the same contact, one update will be silently overwritten. The fix is to configure sync direction per field rather than per object - decide which system owns each piece of data and only allow writes from that direction for that field.

Candidates without email addresses being skipped silently. The sync typically skips records with missing required fields without surfacing a visible error in the main interface. You find out by checking the sync health dashboard and seeing "missing required field" reason codes. In a typical recruitment database, a meaningful proportion of candidates were added quickly without a full email address. Audit for this before activating.

API rate limits on the Bullhorn side. Bullhorn's REST API rate limits are typically around 100 requests per minute on standard tiers, though this varies by contract. A large initial sync or a high-frequency custom integration can hit these limits and produce 429 errors. If you're on the custom API route, build rate limit handling in from the start. The native Data Sync manages this internally, so it's primarily a concern for custom builds.

Custom field mappings not appearing due to plan gating. Covered in prerequisites, but worth flagging again because it causes real confusion. If you're trying to map a custom Bullhorn field to a custom HubSpot property and you're not on Data Hub Starter, the mapping option simply won't appear in the UI. No error, no explanation. If you're hitting this and you're unsure what your plan covers, raise it with HubSpot support directly - the plan page doesn't always make the Data Sync limitations obvious.

Credential expiry breaking connections silently. Bullhorn session tokens expire on inactivity. For custom integrations, this means the integration stops working with no alert unless you've built monitoring in. For the native Data Sync, a broken authentication shows as a disconnected status in the Data Sync settings - check this monthly as a minimum and set a calendar reminder if you're not actively logging into HubSpot regularly.

Getting a Bullhorn-HubSpot integration right - whether that's the native sync configured properly or a custom build - takes more thought than it looks like from the outside. If you want a second opinion on your setup or you're trying to work out which route makes sense for your specific situation, the Revenue Audit at stacklogic.co.uk/services is a good starting point.