ATS integration and the public API
Most teams are not replacing their ATS. They are adding a screening layer in front of it, which only works if the two systems agree on what a candidate is.
CalHire connects to existing applicant tracking systems through deep bidirectional connectors for Workday, Greenhouse, Lever and SAP SuccessFactors, a generic outbound-webhook connector for everything else, and a REST API with signed webhooks. Requisitions can be imported and stage changes and hires exported. Identifying candidate data is only ever synced after a candidate has consented to an identity reveal for that employer.
Last reviewed
The short version
- Deep connectors for Workday, Greenhouse, Lever and SAP SuccessFactors; a generic webhook connector for anything else.
- Nothing identifying leaves CalHire before a reveal, which is what keeps anonymous screening intact across a system boundary.
- A REST API with signed webhooks covers cases no connector fits.
- Adding a vendor means adding a connector, never changing the sync engine.
The integration problem nobody mentions in the demo
An anonymous screening layer and a conventional applicant tracking system disagree about something fundamental. The ATS is built around a candidate record with a name on it, because that is what every downstream process expects: the offer letter, the background check, the onboarding task, the payroll record. CalHire is built around a candidate who deliberately has no name until they choose otherwise.
Connect the two naively and the anonymity evaporates on first sync. The screening layer is careful, the ATS receives a record, and somewhere a recruiter is looking at a name that was supposed to be withheld for another two stages.
The resolution is to make the sync boundary respect the reveal boundary. Anonymous candidates exist only within CalHire. Nothing identifying crosses into your ATS until the candidate has consented to a reveal for your organisation, at which point a normal named record is exactly what you want.
What connects, and how deeply
Workday
A hired candidate creates a new-hire onboarding record. Post-reveal only, so the record arrives complete rather than as a placeholder someone has to fix later.
Greenhouse
Bidirectional. Import open requisitions so a role is defined once, and export stage changes and hires as the pipeline moves.
Lever
Bidirectional. Import postings, export opportunity stages and hires.
SAP SuccessFactors
Bidirectional. Import requisitions, export candidate stages and hires.
Generic webhook connector
The pattern the others are built on, exposed for any ATS or internal system that can receive an outbound webhook. Most in-house systems land here.
REST API and signed webhooks
For workflows no connector models. Signatures are verified before any processing, so a forged callback does not reach your data.
A typical integrated flow
- 1
A requisition arrives from your ATS
Imported rather than retyped, so the role your team approved is the role candidates see. No drift between the requisition and the posting.
- 2
Screening happens in CalHire, anonymously
Assessment, interview, ranking, shortlisting. Your ATS holds the requisition and nothing else during this phase, because there is nothing else it should hold yet.
- 3
A reveal is requested and consented
The identity boundary is crossed once, deliberately, with a record on both sides of it.
- 4
The named candidate syncs out
Stage changes and hires flow to your ATS from that point on. What arrives is a real person at a real stage, which is what every downstream system was expecting all along.
Why a connector rather than a field mapping
Every ATS models hiring slightly differently. A Greenhouse stage is not a SuccessFactors stage, and neither maps cleanly onto a Workday onboarding record. A single configurable field-mapping layer that claims to handle all of them ends up either shallow or unmaintainable, usually both.
So each vendor gets its own connector implementing a common interface, resolved by a factory at runtime. The sync engine knows about operations, retries, ordering and failure handling. The connector knows about one vendor’s API and nothing else.
The benefit shows up when something changes. A vendor deprecating an endpoint touches one file. Adding a new ATS is a new connector, not a change to the engine every existing customer depends on.
What this does not do
It does not sync anonymous candidates anywhere. If your reporting needs a headcount of everyone who applied, that number lives in CalHire’s analytics, not in your ATS, and it will not appear there no matter how the integration is configured.
It does not replace your ATS, and it is not trying to. Offers, onboarding, headcount planning and the system of record stay where they are. This is a screening layer that hands over a verified, consented, named candidate.
A bidirectional connector cannot resolve a conflict it was not told about. If a stage is changed in both systems between syncs, one write wins and the operation is recorded. Teams that edit stages in both places will eventually be surprised by this, and the answer is a convention about which system owns stage state rather than a cleverer merge.
The generic webhook connector is a pattern, not a turnkey integration. Something on your side has to receive it and do the right thing. For an in-house ATS that is usually an afternoon; for a heavily customised deployment it is a project.
Questions people actually ask
Which applicant tracking systems have deep connectors?
Does our ATS ever see anonymous candidates?
Can we import requisitions instead of creating roles twice?
How are webhooks secured?
What happens when a sync fails?
Is there an API for something no connector covers?
Related
Where this connects to the rest of the platform.
Identity broker and staged reveal
CalHire holds the candidate’s identity. An employer requests it, the candidate consents or declines, and consent releases it to that one employer with an immutable record.
Enterprise controls
SAML single sign-on, job-scoped permissions, departments and approvals, custom domains, white-labelling and data residency, with tenant isolation enforced in the database.
For recruitment agencies
Run a verified talent pool across multiple clients under your own brand, with client workspaces kept separate and placement commissions tracked in a ledger.
Read the reasoning
The evidence and the argument behind what is on this page.
Does an ATS really reject your résumé? What actually happens
The "75% of résumés are rejected by robots" claim has no verifiable source. What an ATS actually does, where filtering really happens, and what to do about it.
ReadTime-to-hire is a throughput metric. Quality-of-hire is the one that matters
Speed metrics are easy to collect and easy to game. How to measure whether your hiring decisions were any good, and which metrics to pair with which.
ReadWhy candidates get ghosted, and how to actually stop
Ghosting is almost never malice. It is what happens when closing the loop is optional, unowned and manual. The four structural causes, and the fix for each.
ReadSee a verified pipeline for one of your roles
Post a role free and review anonymous, skill-ranked candidates. No card, no sales call to get started.