Every ATS integration that fails does so for the same reason: the API worked fine, and the two systems still disagreed about what a record meant. Bullhorn, Greenhouse, Workable, Teamtailor and JobAdder all publish documented APIs. None of them ship an opinion on what your CRM calls a stage, which field is the source of truth for a candidate's phone number, or what happens when a job closes in one system and stays open in another. That gap is where the integration actually breaks, and it is rarely where anyone thought to look.
What breaks is never the API, it's the agreement between two systems
An API call either works or it throws an error. That part is usually fine. What breaks is quieter: system A writes a status of "Interview 2" and system B has no field called that, so it either drops the update or forces it into the nearest bucket, silently, with no error anywhere. Nobody notices until a recruiter or a salesperson is working from a record that has been wrong for two weeks.
This is why "we have an API for that" is not the same claim as "this is integrated." The API is a door. Whether the two systems agree on what walks through it is a separate, unglamorous piece of work, and it's the piece that determines whether the sync holds up under daily use or quietly rots.
Field mapping fails when two systems don't agree on what a stage is called
Pipeline stages are the most common place recruitment system integration breaks first, because every ATS names them differently and every CRM was configured by someone who has never opened the ATS.
Say your ATS has stages: Applied, Screen, Interview 1, Interview 2, Offer, Placed. Your CRM's opportunity stages, set up two years ago by someone in sales ops, are: Lead, Qualified, Proposal, Closed Won. There is no mapping between "Interview 2" and anything in that list. When the sync runs, it either does nothing (the update is dropped, the CRM record goes stale) or someone built a fallback that forces every unmatched stage into "Qualified" (the update lands, but it's wrong).
The check takes fifteen minutes. Pull the full list of stage values from your ATS and the full list of stage values from your CRM, side by side, in a spreadsheet. Count how many ATS stages have no clean match on the CRM side. If it's more than one or two, your integration has been guessing, not syncing.
Candidate records duplicate because the systems key on different fields
The second failure is duplication, and it comes from a mismatch in how each system identifies a unique person. Most ATS platforms key a candidate record on email. Many CRMs key a contact on phone number, or on a combination of name and company that breaks the moment a candidate changes jobs.
Here's the mechanism: a candidate applies through your careers page with roni@gmail.com, gets rejected, and six months later applies again with roni.y@gmail.com, a typo or a new address. The ATS sees no match on email and creates a second candidate record. If the CRM sync then keys off phone number and the candidate used a different number the second time, you now have two candidate records in two systems that don't agree with each other, and a recruiter working the older one has no idea the newer, more current record exists.
This is not a rare edge case. Any team running a careers page and a referral channel side by side will generate typo'd emails and reused-but-different phone numbers every week. The cost isn't the duplicate record itself, it's the recruiter who calls a candidate about a role they already withdrew from, working off the stale copy.
One-way sync means a placement can be open in one system and filled in the other
This is the failure mode that costs the most, because it's invisible to the person it costs money to. Most ATS-to-CRM syncs are built one-way: status updates flow from the ATS into the CRM, not back. That's usually a deliberate, reasonable choice when the build only needs to solve one direction. The problem shows up later, when someone assumes it works both ways and nobody corrects them.
A recruiter closes a job in the ATS. Placed, done, paperwork signed. The CRM never hears about it, because the sync was only ever built to push ATS data outward, not to pull CRM actions back in. Sales sees the role as open in the CRM, quotes against it, maybe even pitches the client on filling it faster. Meanwhile weekly reporting pulls from the CRM and shows an open req that's actually filled, which means your revenue numbers and your headcount numbers disagree until someone catches it by hand, usually the client.
Check this by picking any five roles marked "placed" in your ATS this month and looking up their status in the CRM. If any of them still show open, you have a one-way sync and you're finding out about it later than the client is.
Webhooks fail silently, usually on a Friday
Most modern recruitment system integration runs on webhooks: the ATS fires an event when something changes, and a receiving system listens for it. Webhooks are efficient, and they are also the single most common point of silent failure, because there is no built-in alert when one doesn't arrive. No error message, no red banner, nothing. The event just doesn't fire, or fires and gets dropped by a receiving endpoint that's down for thirty seconds, and nobody is told.
In practice this looks like a candidate stuck in "Interview 1" for four days after they've actually been moved to offer, because the webhook that should have carried that update never landed, or landed while the receiving system was mid-deploy and got lost. Nobody's watching for a candidate that hasn't moved. Everyone assumes the pipeline is just slow.
The one check that catches this: a timestamp of the last successful sync event, visible somewhere a human actually looks, reviewed weekly. Not a dashboard nobody opens, just a number someone glances at every Monday. If that timestamp is more than a day old and new candidates have clearly moved stages in the ATS since then, the webhook has failed and nobody has processed a single update since.
Bullhorn, Greenhouse, Workable, Teamtailor, JobAdder: what the API gives you and what it doesn't
Bullhorn's REST API, Greenhouse's Harvest API, Workable's API, Teamtailor's API and JobAdder's API all let you pull candidates, jobs and stage changes, and all of them let you push updates back in.
None of that tells you how to run your business. They don't know your CRM's stage names. They don't know that your team dedupes on phone number, not email. They don't know that a "placement" in your business means a signed contract, not a stage change, or that your reporting needs a field none of them expose directly and has to be derived from two others. The API is the starting point, a set of doors that open reliably. The mapping, the dedupe logic, the stage translation, the error handling when a call fails, that's the actual integration, and it's built once per business, not shipped once per vendor.
This is the part that gets skipped when a team buys "the integration" as if it were a feature you turn on. ATS api integration in the literal sense, a working API call, is available from all five vendors today. Recruitment system integration, the thing that actually holds up under daily use, is not.
VMS integration is a separate problem, not a variant of ATS integration
If your clients are enterprise accounts using a vendor management system for contingent labor, treat that as a different build entirely, not an extension of your ATS sync. A VMS (Fieldglass, Beeline, and similar systems) adds layers your ATS-to-CRM sync never had to handle: per-client authentication credentials, submission rules that vary by client (some cap submissions per role, some require specific fields before a candidate can even be submitted), and rate cards that differ contract to contract.
Where this goes wrong is when a build gets scoped as "the same as the ATS sync, just pointed at a different system." It isn't. A VMS integration usually needs its own authentication per client relationship, its own field mapping per client's submission form, and its own logic for rate card compliance that has no equivalent on the ATS side at all. Teams that assume VMS integration reuses ninety percent of the ATS build usually find out mid-project that it reuses closer to a third, and the rest is new scope nobody priced.
The audit you can run this week without hiring anyone
You don't need a vendor to find out how bad this actually is. You need a week and a simple tracking sheet.
Start by listing every place a candidate record lives: your ATS, your CRM, any spreadsheet someone keeps "just in case," your VMS if you have one. For each system, mark which one is authoritative for each of the core fields: name, current stage, rate, availability. If two systems both claim to be authoritative for the same field, that's your first finding, and it's usually the one causing the duplicates.
Then, for seven days, have your team log every manual retype: every time someone copies a candidate's status, rate, or contact detail from one system into another by hand because the sync didn't do it. A three-column log works fine: which system it came from, which system it went to, and what field. At the end of the week, count entries per system per day.
If that count is a handful across the week, you have a minor mapping issue, not a systemic one. If it's happening daily and touching three or more systems, you're looking at real retyping cost, and it's worth putting a number on it with the admin cost calculator before deciding what to do about it.
When a native integration or a Zapier job is enough, and when it isn't
Be honest about the boundary here, because it saves money. If you're moving a handful of fields one way between two systems and one of them has a native connector for the other, buy that and stop. A native Bullhorn-to-HubSpot connector or a Greenhouse-to-Slack notification doesn't need a build, it needs someone to switch it on and confirm the field mapping once.
A build is warranted once the audit above shows real cost: more than a handful of weekly retypes, spread across three or more systems, or a two-way sync requirement that no vendor's native connector supports, which is most of them, since most native connectors are one-way by design. If your audit comes back with two or three retypes a week touching two systems, the honest answer is to leave it alone. The fix would cost more than the problem.
Regna Operations builds this kind of single source of truth inside the accounts you already run, mapped to your actual stage names and dedupe rules, not a generic connector. If job status updates are going one way and reporting is wrong because of it, or your team is doing order and data entry by hand between systems that are supposed to talk to each other, that's exactly the kind of use case the Revenue Roadmap is built to price before anyone touches a build.
Common questions
Is ATS integration the same as a Zapier connection?
No. Zapier moves single fields between two apps on trigger, it does not resolve field mapping conflicts or dedupe candidate records, so it works for simple one-way updates and breaks down once three or more systems need to agree.
Do Bullhorn, Greenhouse, Workable, Teamtailor, and JobAdder all have APIs?
Yes, all five publish a documented API, but none of them ship a mapping for your specific stage names, dedupe rules, or CRM fields, that logic has to be built.
What's different about VMS integration compared to ATS integration?
A VMS adds per-client authentication, submission rules, and rate cards on top of the ATS data, so it needs its own mapping rather than reusing the ATS sync.
How do I know if a broken integration is worth fixing now?
Run the one-week audit: count retypes per system per week, if it's a handful, a native connector likely covers it, if it's daily across three or more systems, it's costing more than a build would.
