Lever Greenhouse integration

What a Lever to Greenhouse integration actually does

Lever and Greenhouse are both applicant tracking systems, so you rarely run them side by side for fun. You end up bridging them for a concrete reason: you are switching from Lever to Greenhouse and need years of hiring history to arrive intact, or an acquisition left two teams on two ATSs and recruiting has to operate as one, or a phased rollout means some departments live in Greenhouse while others finish out in Lever.

In every case the real work is the same. Lever holds candidates, their opportunities against specific postings, the stage each one sits in, who sourced them, the interview feedback, the resume, and the offer. Greenhouse expects all of that as candidates with applications on jobs, moved through job-specific stages, attributed to real Greenhouse users. A Lever to Greenhouse integration closes that gap so recruiters do not re-key pipelines by hand and no candidate quietly disappears in the move.

What data moves

Lever object / event	Becomes in Greenhouse	Notes
Candidate	Candidate	Deduplicated on email plus stable Lever ID; one person, one record
Opportunity	Application on a job	Lever’s one-to-many opportunities collapse onto Greenhouse applications
Posting	Job / job post	Mapped to an existing Greenhouse job; new postings matched by requisition
Stage	Job stage	Per-job crosswalk - Lever’s pipeline stages are not Greenhouse’s interview-plan stages
Source / origin	Source	Reconciled to Greenhouse’s source taxonomy, not passed through raw
Feedback form	Scorecard / note	Structured where it maps, attached as a note where it does not
Resume / file	Attachment	Fetched from Lever and re-uploaded, not linked by expiring URL
Note	Activity / note	Preserves author and timestamp for the audit trail
Offer	Offer	Where the Harvest API allows write; otherwise attached as a document
User (recruiter)	User (On-Behalf-Of)	Mapped to a valid Greenhouse user so actions are attributed correctly

The stage crosswalk, source mapping, and user mapping are agreed once at the start and encoded in the pipeline. After that, nobody re-maps them by hand.

The details that break naive exports

A CSV export out of Lever and a bulk import into Greenhouse gets you a list of names and very little else. The expensive part is everything the two data models disagree about:

• Opportunities versus applications. One Lever candidate with three opportunities is one Greenhouse candidate with three applications - not three candidates. Miss this and you seed Greenhouse with duplicates on day one, then spend weeks merging them by hand.
• Stages do not line up. Lever stages are configured at the pipeline level; Greenhouse stages belong to each job’s interview plan. There is no global mapping - it is per-job, and a candidate landing in the wrong stage skips or repeats interviews.
• Greenhouse write rules. The Harvest API throttles writes and requires an On-Behalf-Of user on create and update calls. A naive loop hits the rate limit, drops records mid-batch, or attributes every action to a service account. The pipeline has to back off, retry, and carry the right acting user.
• Attachments expire. Resumes referenced by a Lever download URL will not still resolve when Greenhouse tries to fetch them later. Files have to be pulled and re-uploaded as real attachments during the run.
• Consent and demographic data. EEO and equal-opportunity answers are special-category data. Copying them across without a lawful basis is a DSGVO problem, not a convenience. What moves is decided per field, not by default.
• Idempotency. A migration that cannot be safely re-run is a migration you are afraid of. Every record needs a stable key so a second pass updates rather than duplicates, and so a failed batch can resume exactly where it stopped.

How we build and run it

We treat this as a pipeline, not a one-off script. Lever candidates, opportunities, feedback, files, and offers are read through the Lever API, validated, transformed into your agreed Greenhouse mapping, and written through the Harvest API with the correct On-Behalf-Of user and a retry-and-backoff loop tuned to Greenhouse’s rate limits.

The pipeline is idempotent: every Lever record carries a stable identifier, so a retry or a re-run reconciles against what already exists in Greenhouse instead of creating a second copy. It runs on cloud-native, fully EU-hosted AWS infrastructure, so candidate data never leaves the EU - which keeps your DPA / AVV and your DSGVO obligations clean, and gives your Betriebsrat a straight answer about where applicant data lives.

Then we keep it running. For a cutover that means a monitored, resumable backfill and a verified reconciliation report. For a parallel run it means ongoing change detection, monitoring, alerting, incident response, and watching for Lever and Greenhouse API changes - all our responsibility under contract, with a named owner and an SLA.

When this integration is worth building

If you are moving a few dozen active candidates and have no interest in historical pipelines, do it by hand or with a spreadsheet and Greenhouse’s bulk import - and we will tell you so. The managed pipeline earns its place when you are migrating years of hiring history, when Lever’s opportunity model and Greenhouse’s job stages have to be reconciled at scale, when two ATSs must run in parallel through a phased rollout, or when candidate consent and demographic data mean the move has to be provably compliant rather than a best-effort copy.