Seen on top review platforms
Bullhorn can be your source of truth, until data lands in the wrong field, sync fails silently, or the website shows yesterday’s jobs. Then your team becomes the integration, and everyone hates it equally.

Some facts
sync directions matter: Bullhorn to your site, and the site back into Bullhorn.
entities usually need mapping: jobs, candidates, clients, and activities.
silent failure costs the most: errors that do not trigger an alert.
Whether you’re connecting Bullhorn to a WordPress careers site, a custom portal, or tools like Greenhouse, Lever, Teamtailor, or Recruitee, we’ll design the sync around real constraints, not “should work” assumptions.
We’ve been building and maintaining digital products long enough to know what breaks, what scales, and what “urgent” actually means.
Studio Ubique works with startups, agencies, and mid-sized companies who want their product to work better than their competitors’ excuses. Since 2012, with clients across 15+ countries.
The questions that come up most often, answered here. Yours not among them? Just ask, there's a human on the other end.
Bullhorn integrations typically sit at the higher end of the broader ATS integration range, between €15.000 and €30.000 for the build. Bullhorn is more complex than most modern ATS platforms: the REST API has its own rate-limit behaviour, six different entity types usually need mapping (jobs, candidates, notes, activities, placements, submissions), and custom fields per instance add to the scoping work. A simple read-only integration (jobs from Bullhorn to a WordPress careers site) starts lower, around €10.000. Bidirectional sync with custom field mapping, multi-entity write-back, and audit logging lives at €25.000 to €30.000+. Hourly rates run €60 to €65 across all roles. A short call with your Bullhorn instance details and an example careers site URL is usually enough for a realistic range within a week.
Standard entities: jobs, candidates, notes, activities, placements, submissions, clients, contacts. Both directions where useful: jobs flow out from Bullhorn to the site, application submissions flow back into Bullhorn as candidate records with the right tags and source attribution. Custom fields are common in Bullhorn instances and we handle them as part of scoping. Studio Ubique builds the field mapping document during phase one, with every Bullhorn field, every site field, and every transformation rule visible in one table. That mapping doc is what stays in your handover folder after the project, so future agencies or in-house developers can pick up the integration without reverse-engineering it. Our FlevoDirect case shows a similar entity-mapping setup on a different ATS, illustrating the approach in practice.
Both work. Most Bullhorn-connected careers sites we build run on WordPress because the editorial flexibility matters for recruitment marketing (landing pages per vertical, employer branding pages, ABM landing pages for direct outreach). Custom CMS or headless setups make sense when the site has heavy customisation that WordPress can’t comfortably support, when stakeholders want a specific tech stack, or when the careers site is part of a larger product with its own backend. The Bullhorn integration layer itself is the same regardless: a Node or PHP service that handles the API calls, caching, and write-back logic. Custom recruitment websites remain the broader service, with Bullhorn integration as one technical component.
A mix, depending on the entity. Bullhorn’s webhook support has historically been limited compared to modern API-first ATS platforms. For real-time-ish updates we use webhooks where Bullhorn supports them (mostly for high-volume entities like candidate updates). For everything else, scheduled polling at intervals appropriate to the entity: jobs every 5-15 minutes is usually plenty, candidate updates every few minutes if active recruiting, notes and activities on a longer schedule. Caching sits between the site and Bullhorn so filters and category browsing don’t hammer the API on every visitor click. The honest answer to “real-time?” is “near real-time” — a 30-second to 5-minute delay on most entities, which candidates and recruiters won’t notice in practice.
Bullhorn for Salesforce (BH for SF) is a different product line that runs inside Salesforce as a managed package. Standalone Bullhorn (sometimes called “Bullhorn ATS” or “Bullhorn CRM”) is the original product with its own data model and APIs. Integration approaches differ. Standalone Bullhorn uses the Bullhorn REST API directly: cleaner, more documented, easier to work with. Bullhorn for Salesforce uses Salesforce APIs (REST, SOAP, Bulk) plus Salesforce-specific object models, which means more Salesforce expertise is needed and rate limits work differently. If you’re not sure which Bullhorn variant you have, the simplest test: do you log into Salesforce.com to use it (BH for SF) or directly into Bullhorn.com (standalone). Studio Ubique handles both, but the scoping conversation, the timeline, and the cost differ.
A simple Bullhorn-to-site read-only feed takes three to four weeks from kickoff to live, slightly longer than other ATS systems because of Bullhorn’s auth and rate-limit handling. Standard integration with field mapping, write-back, and basic monitoring runs six to ten weeks. Complex setups with multi-entity sync, custom field mappings, multi-region Bullhorn instances, or BH for Salesforce variants run three to five months. The main variable is rarely our side. Bullhorn API credentials and partner-tier access (sometimes needed for higher rate limits) can take days or weeks to organise depending on your Bullhorn account manager. The faster that moves, the faster everything else does. For the broader context of how ATS integrations work in general, our ATS integration page covers the wider approach.
Book a quick 30 min video call, we will show you exactly what to fix. We reply within 24 hours.