Bullhorn is the most widely used ATS in UK recruitment. It’s also the most requested integration when agencies come to me for a new website. The goal is always the same: post a job in Bullhorn and have it appear on the website automatically, then have candidate applications flow straight back into Bullhorn without anyone at the agency doing anything manually.
This post explains how that integration actually works, what Bullhorn’s API provides, what the build involves, and what you need to have in place before the work can start.
What Bullhorn’s API gives you
Bullhorn has a well-documented REST API that exposes most of the data in your Bullhorn instance as readable and writable endpoints. For a website integration, the most relevant capabilities are:
Job listings. Your active jobs in Bullhorn — title, description, location, salary, sector, job type — are available via the API and can be pulled to your website in real time. Post a job in Bullhorn, it appears on your website within seconds. Close the job in Bullhorn, it disappears from the website automatically.
Candidate creation. When someone applies via your website, the API can create a candidate record in Bullhorn, populate the standard fields (name, email, phone, location, right to work), and associate the application with the specific job they applied for.
CV attachment. CVs uploaded via your website application form are attached directly to the candidate record in Bullhorn. No manual upload. No emailing CVs between systems.
Contact creation from employer enquiries. When an employer submits an enquiry form on your website, the API can create a contact record in Bullhorn with the company name, contact details and enquiry notes — so the lead sits in your CRM from the moment it comes in.
Workflow triggers. Depending on your Bullhorn configuration, an application can trigger specific workflow steps — moving the candidate to a particular status, assigning them to a consultant, triggering an automated acknowledgement email.
What the integration looks like from the candidate’s perspective
A candidate visits your website and sees your live job listings, filtered by sector, location or job type. They find a relevant role, click through to the job page, and apply via a form — name, email, phone, right to work, CV upload, covering note if required. They submit. They receive an automatic acknowledgement email. That’s it from their end.
On the Bullhorn side: a candidate record exists, the CV is attached, the application is linked to the job, and whatever workflow step you’ve configured has been triggered. A consultant reviewing the job in Bullhorn sees the application alongside any other applications from other sources.
What you need in place before the build can start
API access enabled on your Bullhorn subscription. Most standard Bullhorn plans include API access, but it’s worth confirming with your Bullhorn account manager before the project starts. If API access isn’t included on your plan, Bullhorn can enable it — usually without upgrading your plan, though this varies.
API credentials. Bullhorn issues API credentials — a client ID and client secret — through their support process. These take a few days to set up. It’s worth initiating this early as it’s occasionally a bottleneck.
Agreement on what data maps where. Bullhorn has standard candidate fields and custom fields specific to your instance. Before the build, we agree on which fields in your Bullhorn candidate record get populated from the website application form. If you’ve added custom fields in Bullhorn that you want populated from the application, those need to be specified upfront.
A decision on job filtering. How candidates filter jobs on your website — by sector, location, job type, salary range — maps to data fields in your Bullhorn job records. If your job data in Bullhorn is inconsistently structured, this can create filtering issues. It’s worth auditing your job data structure before the build.
What the build involves
The integration sits between your website and Bullhorn’s API. When a page loads on your website, it makes a request to a server-side proxy that authenticates with Bullhorn and returns your live job data. The proxy handles authentication, caches responses to avoid unnecessary API calls, and rate-limits requests to stay within Bullhorn’s API limits.
The application submission works in reverse: the form data from your website is sent to the proxy, which creates the candidate record in Bullhorn via the API, uploads the CV, links the application, and returns a success or failure response to the website user.
The key word is server-side. Your Bullhorn API credentials must never appear in your website’s client-side code — they’d be visible in the browser and usable by anyone who found them. The proxy handles all authenticated requests server-side, keeping credentials secure.
Common problems with Bullhorn integrations
Rate limits. Bullhorn’s API has rate limits — the number of API calls you can make per minute. On a low-traffic site this is never an issue. On a site with many concurrent visitors all loading job listings simultaneously, it can be. Caching job data server-side solves this without any visible impact on the candidate experience.
Custom field mismatches. Bullhorn instances vary significantly in how they’re configured. Custom fields, custom statuses, custom workflow steps — all of these are specific to your instance and need to be mapped explicitly during the build.
Authentication expiry. Bullhorn’s API uses OAuth with access tokens that expire. The integration needs to handle token refresh automatically — if it doesn’t, the job feed stops working when the token expires. This is a standard part of a properly built integration, but worth checking if you’re evaluating an existing integration that’s stopped working.
Vincere, Jobadder and other ATS platforms
The same integration pattern applies to other ATS platforms with REST APIs — Vincere, Jobadder, Mercury xRM. The specific endpoints, authentication methods and data structures differ, but the architecture is the same: server-side proxy, authenticated requests, cached responses, form submissions creating records.
If your ATS isn’t on that list, get in touch with the name of your system. If it has a documented API, the integration is almost certainly possible.
For full details on what’s included in a Bullhorn or Vincere website integration, see the recruitment website design service page. The Full Integration tier covers the complete Bullhorn connection — live job feed, candidate creation, CV attachment and employer enquiry handling — at a fixed price.
If you’re also looking to verify client companies automatically when a new employer record is created in Bullhorn, the Companies House API integration can run alongside this — checking company status, directors and registered address at the point of onboarding.
Related posts
Need help with your website?
I work directly with small businesses on web design, WordPress fixes, Shopify support and local SEO. No agency overhead.
Get in touch →