Bullhorn API: what a real integration involves
OAuth 2.0 gets you a session token against a documented entity model of candidates, job orders and placements. Whether that's enough depends on if you're building for one desk or listing on the Marketplace.
Answered in short
5 things that decide this
- 01Bullhorn's REST API runs on OAuth 2.0. You get an access token through the standard flow, then swap it for a BhRestToken session key that carries every call after that.
- 02The entity model is built for staffing. Candidate, JobOrder, Placement, ClientContact and ClientCorporation are the core objects, alongside Note, Task and Appointment, each with fields you query and write against directly.
- 03Building against your own agency's instance is a different track from listing on Bullhorn's Marketplace for other agencies to install. The second goes through Bullhorn's own review, and we confirm the current requirements during the audit.
- 04The API covers what a desk actually needs: reading and writing candidate records, job orders and placements, and attaching notes and tasks that show up in a recruiter's normal Bullhorn screen, not a separate tool nobody opens.
- 05What your instance exposes, custom fields, workflow rules, the modules your agency runs, varies by account. We confirm the details against your Bullhorn setup during the audit, before scoping a build.
The entity model matches how a desk actually works
A lot of vertical software makes you translate your own workflow into the vendor's terms. Bullhorn's entity model doesn't ask for that. The names are already what a recruiter thinks in: a Candidate, a JobOrder, a Placement, a ClientContact at the firm that opened the req. That's why agents built on Bullhorn tend to feel native, not bolted on, once the link itself is working.
Getting the connection working starts with OAuth 2.0. An access token comes back through the normal login flow. That token gets swapped for a BhRestToken, the session key every call after that carries. It's a two-step handshake, not one bearer token doing everything. That's worth knowing before a build assumes step one's token is the one it uses everywhere.
Your own instance versus the Marketplace
Two different questions hide under the same phrase, "Bullhorn API access," and they have different answers. Building a custom tool against your own agency's Bullhorn, for your own desks, is a matter of API credentials and the entity model above. Listing a product on the Bullhorn Marketplace, so other agencies can install it, is a separate track. Bullhorn's own review process decides what gets listed there and how it behaves inside a customer's account.
Most of what your agency needs, screening agents, resurfacing, compliance gates, redeployment check-ins, is the first kind. It's a build for your own instance, tested against your own data. It never needs to clear a marketplace review at all. We confirm which track applies during the audit. Bullhorn's own programme terms are the real authority here, not a general assumption.
- Resume or intake arrivesParsed and matched against the Candidate entity
- Screening passRanked shortlist with reasons; recruiter decides
- SchedulingWritten as a Task or Appointment on the record
- ResurfacingExisting candidates matched when a new JobOrder lands
- Redeployment check-inA note logged on the Placement as a contractor's assignment ends
Every one of these writes into Bullhorn objects a recruiter already works in.
Screening, resurfacing, redeployment and compliance gates
Screening and scheduling agents are what agencies ask for most. They run a first pass on new candidates against a JobOrder's needs. They write a ranked shortlist with reasons back as a Note. Then a recruiter makes the real call. The decision stays human, and you get back the five to ten minutes a manual first read takes on every resume.
Resurfacing tends to matter more than you'd expect going in. A Bullhorn base piles up years of records, and most never get pulled back up. Nobody's search finds a fair match twice. An agent that scans your pool on each new job finds people you already own, not people you have to find again.
Compliance gates and redeployment check-ins both write to the Placement record as the source of truth. A gate blocks dispatch until right-to-work or a credential is confirmed. A check-in logs a note as a contractor's assignment winds down. Your desk sees a warm bench, not a candidate who's gone quiet.
- 01Screening agents that rank candidates against a JobOrder and write reasons a recruiter can check, not just a score.
- 02Resurfacing that re-reads the Candidate pool on every new JobOrder, instead of leaving it to a fresh Boolean search.
- 03Compliance gates on the Placement record that block dispatch until the check clears, logged rather than reported after the fact.
Some of the systems we have shipped
Related questions
01Can a small agency get Bullhorn API access without going through Marketplace?+
Yes. A custom build for your own agency's instance is a different, simpler track than a Marketplace listing meant for other agencies to install. Most single-agency automation projects never need to touch the Marketplace review at all.
02Does Bullhorn charge extra for API access?+
Bullhorn's own documentation doesn't publish a required fee specific to API access in the general reference material. Treat any specific figure a vendor quotes as a claim to verify against your own account, not an assumed fact.
03What's the BhRestToken, and why does it matter?+
It's the session key you exchange your OAuth access token for, and it's what every subsequent REST call actually carries. A build that treats the initial OAuth token as the one used everywhere will break; the exchange step is required.
04Can an AI screening agent auto-reject candidates on its own?+
That's your agency's call, not something the API enforces either way. The pattern that holds up under quality and compliance scrutiny is ranked-with-reasons. The agent surfaces its shortlist and its reasoning. A recruiter makes the reject or advance call.
05What does Hashlogics actually do on a Bullhorn project?+
We start by confirming what your specific instance exposes, custom fields, workflow rules and any modules in play, against your own account during the audit. The build gets scoped from what we find there, not from the general API documentation alone.
Related
- AI, automation and custom software for staffing agencies →The wider build across screening, compliance and redeployment.
- Custom software for accounting, insurance and staffing firms →Where a Bullhorn integration fits inside a wider back-office build.
- Recruiter admin hours calculator →Put your own screening volume against the math.
