Field notes
The Apollo-to-Bullhorn shuffle is quietly eating your margin
6 July 2026
On this page
A BD lead at a mid-size engineering recruiter runs Apollo searches every morning. She finds twelve contacts worth sequencing. She copies the name, title, company, LinkedIn URL, and email into a spreadsheet. By the end of the week, she pastes them into Bullhorn. By then two of the contacts have already been touched by a colleague. One has been placed. The notes from the Apollo sequence never make it across. The Bullhorn record shows the company but not the conversation.
Multiply that by five consultants and fifty working days and you have a data quality problem that no amount of Bullhorn reporting will surface, because the system only knows what it was told.
This is not a technology failure. It is a workflow design failure that a dropped integration made visible.
Apollo removed its native Bullhorn integration from the marketplace in late 2024. The official line was that the integration was deprecated in favour of API-based custom builds. In practice, agencies that relied on it were left with a gap and no obvious replacement. Most filled that gap with manual effort. That effort is now a fixed overhead sitting inside every BD motion, compounding quietly.
This playbook covers the integration patterns that replace the shuffle, in the order you should build them.
Before you build anything, you need to know what data is moving, how, and how often. Most agencies cannot answer this precisely. They know "the team uses Apollo and Bullhorn" but not which fields transfer, which get dropped, and how stale the average record is by the time it lands.
Run this audit first. It takes two hours and it will tell you which integration pattern to prioritise.
What to capture:
- Which consultants are copying from Apollo manually, and how frequently
- Which fields they copy (name, email, company, title, LinkedIn, sequence status, last touch date)
- Which fields they skip (usually: sequence step, open/reply status, any Apollo tags)
- Average lag between Apollo contact creation and Bullhorn record creation
- Duplicate rate: pull a sample of 200 recent Bullhorn contacts and check how many appear twice
The duplicate rate is the number that matters most. If it is above 8 percent, you have a merge problem that will follow you into any new integration unless you resolve it first. Bullhorn's deduplication logic matches on email by default. Apollo often holds multiple email variants for the same contact. The shuffle creates duplicates because consultants do not check before they paste.
Do not skip the audit. Every agency that has skipped it has built the integration and then spent two months cleaning up the records it created.
There are three viable patterns. The right one depends on your technical resource and your tolerance for maintenance.
Pattern A: Zapier or Make with field mapping
The fastest to ship. Apollo has Zap triggers for new contacts added to a list and for sequence completions. You map those triggers to Bullhorn's REST API via a Zapier or Make scenario. You control exactly which fields transfer and in which direction.
Limitations: Zapier's Bullhorn connector is shallow. You can create contacts and update basic fields, but writing to custom fields or associating a contact with a tearsheet or vacancy requires the API directly. Make handles this better if you are comfortable with HTTP modules.
Pattern B: Native API integration via n8n or a middleware layer
More setup, more control. n8n can hit Apollo's API on a schedule (every four hours, say), pull contacts added or updated since the last run, check Bullhorn for an existing record by email, update if found, create if not, and write sequence status to a custom field. This is the pattern I recommend for agencies running more than three consultants on Apollo.
The sequence status field is the one most agencies forget to map. If Bullhorn does not know that a contact is currently in an active Apollo sequence, a consultant can book a call with someone mid-sequence, which breaks the sequence logic and looks chaotic to the prospect.
Pattern C: A dedicated RevOps or GTM data layer
If you are running Apollo, Bullhorn, and a separate email infrastructure, you need a single source of truth that is not any of those tools. Clay is the obvious candidate. You enrich in Clay, push clean records to both Apollo (for sequencing) and Bullhorn (for ATS tracking), and use Clay as the canonical contact record. This is the most durable pattern but the most expensive to build and maintain.
For most agencies reading this, Pattern B is the answer.
This is where most DIY integrations break. Someone builds the Zap, it runs for a week, and then a consultant notices that the "current employer" field in Bullhorn is showing the Apollo list name. Field mapping done in a hurry produces garbage at scale.
Use the table below as your starting schema. Adjust the Bullhorn field names to match your instance's custom field labels.
| Apollo field | Bullhorn field | Direction | Notes |
|---|---|---|---|
first_name | firstName | Apollo → Bullhorn | |
last_name | lastName | Apollo → Bullhorn | |
email | email | Apollo → Bullhorn | Deduplicate on this before write |
organization_name | companyName | Apollo → Bullhorn | |
title | occupation | Apollo → Bullhorn | |
linkedin_url | customText1 | Apollo → Bullhorn | Map to whichever custom field you use |
sequence_name | customText2 | Apollo → Bullhorn | Active sequence name |
sequence_status | customText3 | Apollo → Bullhorn | active / finished / bounced / replied |
last_activity_date | customDate1 | Apollo → Bullhorn | Last Apollo touch date |
owner_email | owner (lookup) | Apollo → Bullhorn | Resolve to Bullhorn user ID |
The owner field lookup is the one that breaks most automations. Apollo stores the contact owner as an email address. Bullhorn stores it as an internal user ID. Your integration needs a lookup step that converts one to the other, or every record lands as unowned in Bullhorn and disappears from consultant dashboards.
Every write to Bullhorn should run a search-before-create step. The logic is:
- Take the incoming email from Apollo.
- Query Bullhorn's
search/ContactCandidateendpoint for that email. - If a record exists, update it. If not, create it.
- Log the outcome (created / updated / skipped) to a simple audit table.
The audit table is not optional. Without it you cannot tell your team how many records the integration is touching per day, and you cannot diagnose when it silently fails. Silent failures are the most common failure mode in webhook-based integrations: the trigger fires, the step errors, no one notices, the manual shuffle resumes.
For more on what silent failures look like across an automation programme, the patterns behind most AI pilot failures are worth reading before you commit resource to this build.
Once sequence status is flowing into Bullhorn, create a view or saved search that shows every contact currently in an active Apollo sequence. Train consultants to check this before booking outbound calls or sending manual emails to a prospect.
This is the step that closes the loop. Without it, the integration moves data but does not change behaviour. A consultant who does not know a contact is mid-sequence will still double-touch them.
The same logic applies to candidate records. If you are using Apollo to source passive candidates and sequencing them before they are formally in process, Bullhorn needs to reflect that status so no one calls them cold from a different desk.
The field mapping review at ninety days.
Agencies build the integration, it works, and they leave it. Three months later Apollo has updated its contact object and added a field. Bullhorn has had a schema change from a plugin update. The integration is still running but three fields are now writing to the wrong place. No one notices because the records look roughly right.
Book a ninety-day review into the calendar the day you go live. Pull twenty-five records, compare Apollo source data to Bullhorn destination data field by field, and check the audit log for error rates. If errors are above two percent, investigate before they compound.
This is the same discipline I wrote about in the context of CRM data quality for compliance workflows: the integration is not the end of the work, it is the start of a maintenance cycle. Treat it that way and it holds. Ignore it and the drift sets in silently, exactly as it did when the shuffle was manual.
If you want a second opinion on your current Apollo-to-Bullhorn setup before you build, the AI Workflow Audit covers integration architecture, field mapping, and the deduplication logic that most agencies get wrong the first time.