Most Bullhorn website integration projects start with a simple request: get our jobs onto the website without anyone retyping them. That part is usually fine. The trouble starts when the scope grows. Suddenly the site is meant to write candidate records, sync consultant bios, update client data and track every click. Each extra connection adds cost, risk and something that can break on a Friday afternoon.
This guide helps you decide what to connect, what to automate and what to leave alone. It covers job publishing, applications, consultant profiles, GDPR and the failures we see most often. It applies to UK and US agencies, and to any ATS website integration, though the examples are Bullhorn-specific.
What Bullhorn website integration means
Bullhorn website integration is a controlled link between your website and your Bullhorn account, usually through the Bullhorn REST API. Data flows in two directions. Live jobs travel from Bullhorn to the site. Applications and enquiries travel from the site back into Bullhorn.
Bullhorn stays the system of record. The website is a display and capture layer. If you hold that principle, most design decisions become easy. If the website starts storing its own version of jobs or candidates, you now have two databases that disagree.
What to connect, and what to automate
Not everything in Bullhorn belongs on the website. Start with the data that earns its place.
- Published jobs, including title, location, sector, job type, pay and description.
- Job status changes, so filled or closed roles disappear promptly.
- Applications and speculative CVs, written back as candidate records.
- Source data, so you know which page or campaign produced the candidate.
- Consultant contact details for each job, if you show them.
Automate the repetitive, rules-based work. Publishing is the best example. Done well, it follows a set sequence:
- A consultant marks a job as public in Bullhorn and completes the required fields.
- The integration pulls the job on a schedule, or receives a change trigger.
- The site creates or updates the job page, with a stable URL and structured data.
- When the job closes or is unpublished, the page is removed or redirected.
- The sitemap and any job feeds update automatically.
Keep the consultant's job in Bullhorn simple. Make key fields mandatory there, such as location, sector and pay. A website cannot fix a job record that has no location.
Applications sync: where most problems start
Sending an application from a website into Bullhorn sounds easy. In practice it needs decisions about duplicates, parsing and ownership.
Decide first how a web application should appear in Bullhorn. Typically the integration creates or matches a candidate record, attaches the CV and links the candidate to the job as a web response or submission. Your Bullhorn administrator should confirm which route suits your workflow, because it affects reporting and consultant queues.
- Duplicate matching: by email, by name plus phone, or both. Decide what happens on a match.
- CV parsing: whether Bullhorn parses the file, and how failures are flagged.
- Consent: where the candidate's consent or notice acceptance is stored.
- Ownership: which consultant or team receives the application.
- Confirmation: what the candidate sees and receives after applying.
- Failure handling: what happens if Bullhorn is unavailable at the moment of submission.
That last point matters most. A candidate should never see an error page and lose their application. Queue submissions, retry them and alert someone if retries fail.
Consultant profiles: mostly leave alone
Bullhorn holds user records for your consultants, so it is tempting to feed the team page straight from it. We usually advise against a full sync.
Good consultant pages carry a personal bio, a photo, specialisms, a LinkedIn link and sometimes a short market view. Those are marketing assets, not CRM fields. They are best managed in your website's content system, where marketing can edit them without touching Bullhorn.
Connect only the link between the two. Store the Bullhorn user ID against each profile. Then a job can show the right consultant's name, photo and contact details, and a departed consultant's jobs can be reassigned without breaking pages.
GDPR and data protection in the integration
An integration moves personal data, so it falls under UK GDPR, EU GDPR where relevant, and US state privacy laws such as the California rules for applicants. This is not legal advice. Take it to your data protection lead or counsel. Practically, check the following.
- Collect only the fields you need to process an application.
- Show a clear privacy notice at the point of application, and record when it was accepted.
- Do not keep CVs or candidate data on the web server or in email notifications longer than needed.
- Use HTTPS, restricted API credentials and a dedicated API user, not a consultant's login.
- Keep API secrets out of front-end code and out of shared documents.
- Make sure deletion requests made in Bullhorn can reach any copies held elsewhere.
- List the website host, form tools and any parsing services in your processor records.
The simplest approach is to avoid storing candidate data on the website at all. Pass it to Bullhorn and keep nothing beyond a short-lived queue.
Common failure modes
Most integration problems are predictable. These are the ones we see most often.
- Expired or revoked API credentials, so jobs stop updating and nobody notices.
- Ghost jobs, where filled roles stay live because the unpublish step was missed.
- Duplicate candidates created on every application.
- Broken URLs when a job title changes and the page address changes with it.
- Missing fields, such as no location, which breaks filters and Google for Jobs eligibility.
- Rate limits or timeouts during bulk updates, leaving the site partly out of date.
- Custom fields renamed in Bullhorn without telling the developer.
Prevent most of these with monitoring. Log every sync. Alert when no jobs have updated in a set period or when application failures occur. A silent integration is the dangerous kind.
Next steps
Before you brief a developer or supplier, write down which data moves in each direction, who owns each field and what should happen when something fails. Then ask your Bullhorn administrator to confirm API access and the fields you plan to use. Start with job publishing and application write-back, prove them, and only then consider extras.
If you want help scoping or building this, TRG Digital designs and builds ATS integrations for recruitment businesses, including Bullhorn, with monitoring and data protection built in.
Frequently asked questions
Does Bullhorn have an API for websites? Yes. Bullhorn provides a REST API that lets approved applications read and write data such as jobs, candidates and applications. You normally need API credentials issued through Bullhorn, plus a dedicated API user. Your Bullhorn administrator or account contact can confirm access and which entities and fields you can use.
How often should jobs sync from Bullhorn to the website? A typical range is every 5 to 30 minutes, depending on how fast your jobs change. Faster is rarely needed. What matters more is that closed jobs are removed reliably and that failed syncs trigger an alert, so stale roles do not stay live unnoticed.
Should candidate data be stored on the website as well as Bullhorn? Generally no. Treat Bullhorn as the system of record and pass applications straight into it. Holding duplicate candidate data on the website increases GDPR risk, complicates deletion requests and creates records that can drift out of sync. If you need a queue for retries, keep it short-lived.