# Lever Greenhouse integration

*Lever → Greenhouse*

**In short:** A Lever to Greenhouse integration maps Lever's opportunity model onto Greenhouse's candidate-and-application model: each Lever candidate becomes a Greenhouse candidate, each opportunity becomes an application on the matching job, and stages, sources, feedback, notes, resumes, and offers travel with it. Done properly it is not a CSV dump - it is an idempotent pipeline that deduplicates by email, respects Greenhouse's On-Behalf-Of write rules and rate limits, and preserves recruiter attribution and consent so nothing is silently dropped or double-created.

## 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.

## Frequently asked questions

### Are you migrating us off Lever onto Greenhouse, or keeping both running in sync?

Either, and they are different jobs. A one-time cutover backfills your Lever history into Greenhouse once and stops. A parallel-run sync keeps both systems aligned while teams or regions move over in phases, which means change detection, conflict rules, and a clear system of record per field. We scope which one you need before writing a line of pipeline, because the failure modes are not the same.

### How do you reconcile Lever's opportunity model with Greenhouse's candidate and application structure?

In Lever a single candidate can hold several opportunities across different postings; in Greenhouse that is one candidate with several applications. We collapse to one Greenhouse candidate per person, keyed on email plus a stable Lever ID, and attach each opportunity as an application on the mapped job. Without that reconciliation you get duplicate candidates and orphaned applications, which is the single most common way a raw import goes wrong.

### What happens to candidate GDPR data, consent, and EEO or demographic answers?

Those fields are handled deliberately, not swept along by default. Demographic and equal-opportunity responses are sensitive and often should not be migrated at all under DSGVO and the AGG. We agree per-field what moves, what is dropped, and how consent and retention deadlines carry across, so the Greenhouse instance does not inherit data you no longer have a lawful basis to hold.

### Do interview feedback and scorecards survive the move?

Partly, and we are honest about where it is lossy. Lever feedback forms are relatively freeform, while Greenhouse scorecards have a fixed shape - attributes, ratings, and an overall recommendation. We map what maps cleanly and preserve the rest as attached notes or activity entries rather than forcing it into fields it does not fit. You keep the hiring history; you do not get a false impression that structured data existed where it did not.

### Who operates it after go-live, and what about API rate limits and changes?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor, and it is built around Greenhouse's Harvest write throttling and On-Behalf-Of requirements so it backs off and retries instead of failing a batch. If Lever or Greenhouse changes an endpoint, that is our problem to fix under contract. You get a named owner, alerting, and an SLA rather than a migration script nobody dares re-run.

## Related integrations

- [Greenhouse ↔ BambooHR](https://seamless.engineering/integrations/greenhouse-bamboohr/): Greenhouse BambooHR integration
- [Greenhouse ↔ Workday](https://seamless.engineering/integrations/greenhouse-workday/): Greenhouse Workday integration
- [Personio ↔ LinkedIn](https://seamless.engineering/integrations/personio-linkedin/): Personio LinkedIn integration
- [SmartRecruiters ↔ SAP SuccessFactors](https://seamless.engineering/integrations/smartrecruiters-successfactors/): SmartRecruiters SAP SuccessFactors integration
- [Workable ↔ BambooHR](https://seamless.engineering/integrations/workable-bamboohr/): Workable BambooHR integration
- [Amazon ↔ DATEV](https://seamless.engineering/integrations/amazon-datev/): Amazon DATEV integration

## Browse by system

- [All Greenhouse integrations](https://seamless.engineering/integrations/greenhouse/)

## Request a scoping call

Need this integration built and permanently operated? Tell us which systems connect and what data has to move. Fixed-price scoping quote within 48 hours.

- Email: hello@seamless.engineering
- Contact form: https://seamless.engineering/#contact