If you've ever sat in a Bullhorn implementation meeting and watched the consultant gesture vaguely at "automation" while showing you a list view, you've seen the problem this post is about. "Bullhorn automation" means at least three different things in 2026, and most of the people selling it to you don't distinguish between them. This is what an engineer who's actually built against the Bullhorn REST API would tell you on a discovery call.
I'm Robin, I run Laires Labs, a solo AI engineering studio in London. Most of my recruitment-agency builds touch Bullhorn at some point. This is a teardown of what the API actually does, what the Bullhorn Automation product does, what the gap between them is, and what to choose for which job.
The short answer
There are three distinct things called "Bullhorn automation" in 2026. First, the Bullhorn Automation product (acquired from Herefish in 2018), which is a no-code workflow builder for emails, SMS, and tasks scoped to Bullhorn data. Second, Bullhorn's built-in workflow features (saved searches, mass updates, list view actions), which are not really automation but get pitched as such. Third, custom code against the Bullhorn REST API, which is genuine engineering work and the only one of the three that integrates with anything outside Bullhorn. Buyers conflate all three. Most agency pain sits in the third category and most agency budgets get spent on the first.
The two products called "Bullhorn Automation"
Worth getting this straight before anything else.
Bullhorn Automation (the product) is what Bullhorn sells under that name. It started life as Herefish, an outbound recruitment automation tool focused on candidate re-engagement. Bullhorn bought Herefish in 2018, renamed it, integrated it with the core Bullhorn database, and now sells it as an additional per-seat module. It runs from a separate dashboard at automation.bullhorn.com and from inside the main Bullhorn UI. What it actually does well: send templated emails and SMS to candidates and contacts based on triggers in the Bullhorn data, run nurture sequences, send tasks to recruiter dashboards on rules.
Custom code against the Bullhorn REST API is what an engineer means when they talk about Bullhorn automation. The REST API (documented at bullhorn.github.io) lets you read, write, query, and subscribe to changes on most Bullhorn entities. Anything you can do in the Bullhorn UI, you can mostly do via the API, plus things you can't do in the UI like cross-system integrations and bulk transformations.
The reason this matters: most recruitment agencies hear "Bullhorn automation" from a Bullhorn salesperson and assume they're getting the second thing. They're getting the first. When the actual problem is "candidates aren't being enriched from LinkedIn" or "our finance system isn't syncing with Bullhorn placements" or "our compliance dashboard pulls from three places someone has to copy-paste between," the product won't help. You need code.
What the Bullhorn REST API actually exposes
The REST API uses OAuth 2.0 with a per-user authorisation flow. Your custom code logs in as a Bullhorn user (typically a dedicated API user) and operates with that user's permissions. Sessions return a BhRestToken plus a REST endpoint URL specific to your corporation, valid for a configurable session length, with a keepalive endpoint for long-running processes.
Once authenticated, the entity surface is broad. The most-used endpoints in practice:
/entity/{Entity}/{id}: CRUD on a single record. Supports GET, PUT, POST, DELETE./search/{Entity}: Lucene-syntax search across the entity, returns matching IDs./query/{Entity}: SQL-like WHERE clause queries, returns full records./subscription/{name}: change-notification stream for an entity. Long-poll, returns events with a 30-90 second lag./file/{Entity}/{id}: document upload and download for the parent entity./meta/{Entity}: field metadata for the entity in this corporation, including custom field labels and types.
The entities you'll touch in 95% of agency builds: Candidate, ClientContact, ClientCorporation, JobOrder, JobSubmission, Placement, Note, Task, Appointment, plus Lead and Opportunity if the agency uses Bullhorn's CRM features.
Field permissions are the first surprise for engineers new to Bullhorn. Every field on every entity has a per-user-profile read/write/none setting configured inside the Bullhorn admin UI. Your API user only sees and writes what its profile allows. A common gotcha: a field appears in /meta/Candidate but writes to it silently fail because the profile doesn't have write permission. Check /meta against the profile early.
The second surprise: custom fields. Every Bullhorn instance has up to 20 customText fields, 10 customDate, 10 customInt, 10 customFloat, 10 customBigText, plus customer-configured custom objects. The same business concept (say, "right to work expiry date") might be customDate3 in one client's instance and customDate7 in another. Always pull /meta to map the labels you care about to the actual field codes per client. Never hardcode customText5.
What the API doesn't do
The honest gap list, from builds where this has bitten me or other engineers I've talked to.
No bulk patch endpoint. If you need to update 5,000 records, you're iterating one at a time inside the rate limit. The rate limit is roughly 100 requests per second sustained per corporation, with bursts allowed. A bulk update of 5,000 records is therefore 50 seconds at minimum, plus error handling, plus retries. Plan for the throughput, not the wall clock.
Subscription API has lag. The change-notification stream is reliable but events arrive 30-90 seconds after the change. For workflows that need real-time reaction (a candidate accepts an offer, send the contract immediately), polling the entity directly is sometimes more reliable than waiting for the subscription event.
Some data is not exposed. Pulse (Bullhorn's email-tracking and activity-capture product) data is partially exposed but not the full UI feature set. Bullhorn for Salesforce sync state is internal. Some billing and back-office records (specifically certain Pay-Bill data structures) require the legacy SOAP API or a separate Bullhorn One module.
Document handling is fussy. File upload via /file works but the multipart and mime-type handling is stricter than the docs suggest. PDFs, DOCXs, common image types are fine. Less common types (RTF, odt, certain proprietary CAD formats agencies sometimes get) need explicit mime-type headers and occasionally fail silently. Always verify the file appears in the UI after upload.
No GraphQL. The REST API requires you to specify field lists per request and roundtrip per relationship. For a candidate with their last 5 placements, their most recent note, their owning recruiter, and their owning manager, you're looking at 4-5 requests per candidate. Cache aggressively if you need to display this kind of view at scale.
Rate limit accounting is per-corporation, not per-user. If your build shares a corporation with the agency's recruiters using the UI, your background processes can starve interactive users. For high-throughput jobs, schedule for off-hours and batch with deliberate backoff.
What you can actually build
The patterns that actually ship in agency clients. Each of these is a custom build against the REST API, not something Bullhorn Automation does.
Candidate enrichment at ingestion. Subscription on Candidate create events, fan out to an enrichment provider (Apollo, Cognism, Clay, or a LinkedIn-via-Apify pipeline), write the enriched fields back to the Candidate record. The work is in the field-mapping and the enrichment logic, not the Bullhorn calls. Build time: 1-2 weeks. Maintenance: low once stable.
CV-to-submission-ready formatting. Subscription on JobSubmission create or status change, pull the linked Candidate's primary CV from the file API, run an LLM pass to extract structured data and reformat to the agency's client-facing template, upload the new doc back to the JobSubmission file area. Build time: 2-3 weeks. The complexity is in the template definitions and the quality control gate.
Two-way sync to a finance or accounting system. Subscription on Placement create and update, transform to whatever your finance system expects (Xero, QuickBooks, Sage, FreeAgent), POST to the finance API. Reverse direction: webhook from finance system, update Placement billing status. Build time: 3-4 weeks depending on the finance system. Most of the work is on the finance side, not the Bullhorn side.
Cross-client candidate visibility dashboard. A custom UI that pulls from /query/Candidate, /query/JobSubmission, and /query/Placement to show consultants who's available, who's been submitted to which client, and who's blocked from approach. Build time: 4-6 weeks. The data is straightforward; the UX is the work.
Compliance pack collection. Workflow that watches for new Placements, generates the right compliance pack template (right-to-work, references, qualifications), emails the candidate via your own SMTP plus Bullhorn note logging, chases by rule, and uploads received documents back to the Candidate file area. Build time: 2-3 weeks. The chase logic is the interesting part.
LinkedIn-to-Bullhorn pipeline. Apify or LinkedIn Recruiter export, deduplication against existing Candidates by name plus email plus phone, creation or update of Candidate records with source attribution, optional auto-task to the owning recruiter. Build time: 1-2 weeks. The dedup is the work.
None of these are Bullhorn Automation jobs. None of them are Zapier jobs at agency scale (Zapier hits its task limits fast). All of them are 1-6 weeks of custom code that runs on your own infrastructure for the next several years.
When Bullhorn Automation is the right answer
Despite the limitations, the product is genuinely good at what it's built for.
Outbound candidate nurture. Re-engagement sequences against dormant candidates, drip campaigns by skill or location, status-change emails. The product handles deliverability, unsubscribes, sender reputation, and template management without you having to wire SendGrid yourself.
SMS for time-sensitive comms. Interview reminders, shift confirmations, rate confirmations. Built-in Twilio-equivalent functionality.
Recruiter task automation. Rule-based task creation in recruiter dashboards (candidate hasn't been contacted in 90 days, create a task). Saves the recruiter from having to maintain their own follow-up system.
Templated email at scale. Anything you'd otherwise wire SendGrid for, plus the Bullhorn data integration is already done.
What it isn't: a workflow tool for integrating Bullhorn with the rest of your stack. The moment your workflow needs to call an external API that isn't email or SMS, you've outgrown it.
When Zapier or n8n is the right answer
For very simple connect-app-to-app workflows where one Bullhorn event triggers one action in one external tool, and there's no fan-out logic. New JobOrder posts to a Slack channel. Placement created posts to your accounting tool's invoice queue. Candidate updated in Bullhorn updates a row in a Google Sheet someone uses for reporting.
Zapier and n8n both have working Bullhorn integrations. The constraints: rate-limited by Zapier or n8n's own task or execution quota, no real fan-out logic, hard to handle errors gracefully, hard to version-control or audit. Fine for one-off connectors. Painful for anything you'd want to maintain seriously.
When custom code is the right answer
When the workflow involves any of these:
- Two or more external systems beyond Bullhorn
- Conditional logic that branches more than two or three ways
- Bulk operations against Bullhorn data
- An LLM call as part of the decision logic (drafting, summarising, extracting)
- A custom UI that anyone in the business interacts with
- Anything you want to version-control, audit, and own
The threshold I use as a rough rule: if you're describing the workflow and you find yourself saying "and then if X, but unless Y, except when Z" more than once, you're past Zapier and into custom code territory.
What it costs
Bullhorn Automation: roughly £30-£70 per seat per month on top of the core Bullhorn subscription. Pricing isn't public; numbers come from agency clients I've spoken with in 2025-2026. Multi-seat agency contracts negotiate differently.
Zapier or n8n setup by a reseller: £800-£3,000 per workflow as a one-off, plus £40-£200 per month subscription depending on task volume. Reasonable for one or two simple connectors.
Custom build against the REST API: £12,500 upwards as a one-off, plus £100-£300 per month for hosting and LLM API costs if applicable. Floor exists because real builds need scoping, build, error handling, deployment, documentation, and post-launch support. Smaller jobs are better served by Bullhorn Automation or a Zapier reseller.
The custom build path's economic argument: zero per-seat scaling, full ownership, no vendor lock-in beyond Bullhorn itself. A 30-recruiter agency paying for 30 Bullhorn Automation seats sees the maths shift around year two.
A note on Bullhorn Marketplace
The Bullhorn Marketplace lists vendors with pre-built integrations into Bullhorn. For mainstream tools (Cognism, Sourcebreaker, Vincere migration tools, payroll integrations, video interview platforms), the Marketplace partner is usually the right answer. For anything genuinely custom, the Marketplace doesn't help and an engineering build is the route.
Book a call
If you're running a recruitment agency on Bullhorn and trying to work out whether your next workflow problem needs Bullhorn Automation, a Zapier connector, or a custom build, that's the call to book. Twenty minutes, no pitch. Tell me the workflow and I'll tell you which of the three is right and what each one would cost you. You walk away with a one-line answer per option, and a scoped build estimate if custom is the right path.
Don't book if your problem is "send templated emails to candidates", buy Bullhorn Automation. Don't book if your problem is "post a Slack message when a JobOrder lands", buy a Zapier subscription. Both are good products for those jobs.
Book a 20-minute call or read the full recruitment automation buyer's guide if you're earlier in the decision.
Thinking about a system like this?
20-minute call, no slides. We'll map it against your stack and I'll tell you if it's worth building.
Book a callQuestions buyers actually ask
Yes. Bullhorn exposes a REST API (current) and a legacy SOAP API. The REST API uses OAuth 2.0 per-user authorisation and exposes most entities (Candidate, ClientCorporation, ClientContact, JobOrder, JobSubmission, Placement, Note, Task, Appointment) for read and write. Access is governed by a Developer Program account and per-user field permissions inside the Bullhorn instance. Documentation is at bullhorn.github.io and is reasonably complete.
Robin Laires
Ten years software engineering, former tech lead at Jellyfish — one of the UK's largest independent digital agencies. Now I build custom AI systems that replace manual business processes: ads ops, sales intelligence, intake routing, research pipelines. One engineer, installed into your stack.