Source connector

Bullhorn connector

Bullhorn integration for databases, warehouses and BI tools

Staffing CRM covering candidates, clients, and placements. Datrise captures Bullhorn entities such as candidates, job orders, submissions, placements, client corporations and notes, then lands normalized and typed models for warehouse reporting, attribution, and AI workflows.

The Bullhorn REST API authenticates with OAuth 2.0, incremental runs key on dateLastModified.

Of the 6 objects, 5 sync as upserts keyed on the primary key and 1 as append-only streams, so each incremental run moves only what changed since the last watermark. Every object lands in its own table (for example `bullhorn_candidates`) with a schema derived from the Bullhorn API rather than a flattened CSV, in any of the 43 supported destinations.

Datrise is in early access: pick a destination below to open the Bullhorn pipeline page, and join the waitlist to get the Bullhorn connector (CRM) with guided onboarding.

Incremental syncSchema-aware mapping43 destinations available

What Bullhorn data Datrise extracts

Each object lands in its own typed table. Sync mode is derived from the object: history-style objects append, everything else upserts.

Object	Landing table	Sync mode
candidates	bullhorn_candidates	Upsert by primary key, incremental on updated-at
job orders	bullhorn_job_orders	Append-only, incremental by timestamp
submissions	bullhorn_submissions	Upsert by primary key, incremental on updated-at
placements	bullhorn_placements	Upsert by primary key, incremental on updated-at
client corporations	bullhorn_client_corporations	Upsert by primary key, incremental on updated-at
notes	bullhorn_notes	Upsert by primary key, incremental on updated-at

Bullhorn API: setup facts for the connector

Verified against the vendor documentation on 2026-09-02. Unknown values are left blank rather than guessed.

API	Bullhorn REST API
Authentication	OAuth 2.0 — OAuth 2.0 access token is exchanged for a session via a REST `/login` call, which returns a `BhRestToken` session key plus a data-center-specific `restUrl` that must be discovered first via `GET rest-services/loginInfo`.
Pagination	offset — List/query endpoints use `start`/`count` parameters; the default `count` is 20 and the maximum varies by endpoint (e.g. up to 500 for department/`myEntities` calls, up to 10,000 for association calls), with the response reporting the total record count.
Rate limit	Not published
Incremental cursor	dateLastModified — Entities expose `dateAdded`/`dateLastModified` fields that a connector can filter or sort on via the query/search endpoints for incremental extraction.
Webhooks	Not published
Bulk export	No
Deletes detectable	Yes — Soft-deletable entities set an `isDeleted` boolean flag rather than being removed, so a full-refresh query must explicitly include soft-deleted records to see them; some entity types also support a true hard delete.

Official API reference

What bites when replicating Bullhorn

The REST session (`BhRestToken`) is separate from the underlying OAuth token and is only valid on the data-center-specific `restUrl` returned at login; a connector must call `rest-services/loginInfo` to resolve the correct swimlane/data-center URL rather than assuming a fixed hostname.
The default page size on query/search endpoints is only 20 records, and the maximum allowed `count` varies by endpoint (500 for some entity/`myEntities` calls, 10,000 for association calls); using one hard-coded page size across all endpoints will under-fetch on some and needlessly throttle on others.
Rate limiting is documented only as "HTTP 429, wait 1 second, then retry" with no published requests-per-second ceiling, so a connector cannot pre-budget call volume and must implement generic backoff instead.
Query results automatically exclude soft-deleted to-many associations by default, so a connector walking a parent entity's associations will not see records that were soft-deleted (`isDeleted: true`) unless it queries that entity type directly and asks for deleted records explicitly.

Compare this against every other documented API

Popular destinations for Bullhorn

Choose a destination below to open the ready pipeline page.

A
Airtable
Relational spreadsheet destination for ops and go-to-market teams.
View pipeline
A
Amazon Athena
Serverless SQL over S3 data lake tables.
View pipeline
A
Amazon DynamoDB
Serverless key-value and document store on AWS.
View pipeline
A
Amazon QuickSight
AWS serverless BI with SPICE and embedded analytics.
View pipeline
A
Amazon Redshift
AWS petabyte-scale warehouse with Spectrum.
View pipeline
A
Amazon S3 Data Lake
Object storage landing zone for parquet and snapshots.
View pipeline
A
Apache Superset
Open-source BI for SQL exploration, charts, and dashboard publishing.
View pipeline
A
Azure Data Lake Storage
ADLS Gen2 object storage for analytics workloads.
View pipeline
A
Azure Synapse
Microsoft analytics workspace with SQL pools.
View pipeline

Bullhorn connector FAQ

What Bullhorn data does the connector extract?: 6 objects: candidates, job orders, submissions, placements, client corporations and notes. Each lands in its own table with types preserved; history-style objects (1: job orders) load as append-only streams.
Is the Bullhorn integration incremental?: Yes. After the initial full load, every run reads only records changed since the last watermark (updated-at or event timestamp) and applies an upsert or an append depending on the object.
Where can I load Bullhorn data?: Into 43 destinations: relational databases, cloud warehouses, data lakes, spreadsheets and BI tools. Each Bullhorn → destination pair has its own page with the object-to-table mapping.

Related CRM sources

Other sources in the same category, each with its own connector page.

Early access

Launch your Bullhorn pipeline with guided onboarding

Join the waitlist to get priority access for Bullhorn integrations with guided setup, schema-aware mapping, and production-grade incremental sync.