# Lever Greenhouse Schnittstelle

*Lever → Greenhouse*

**Kurz gesagt:** Eine Lever-Greenhouse-Anbindung bildet Levers Opportunity-Modell auf Greenhouses Kandidaten-und-Bewerbungs-Struktur ab: Aus jedem Lever-Kandidaten wird ein Greenhouse-Kandidat, aus jeder Opportunity eine Bewerbung auf der passenden Stelle, und Stages, Quellen, Feedbacks, Notizen, Lebensläufe und Angebote wandern mit. Richtig gemacht ist das kein CSV-Abzug, sondern eine idempotente Pipeline, die per E-Mail dedupliziert, Greenhouses On-Behalf-Of-Regeln und Rate-Limits beachtet und Recruiter-Zuordnung wie Einwilligungen erhält - damit nichts stillschweigend verloren geht oder doppelt angelegt wird.

## Was eine Lever-Greenhouse-Anbindung wirklich leistet

Lever und Greenhouse sind beide Bewerbermanagementsysteme, also betreibt man sie selten zum Vergnügen nebeneinander. Man verbindet sie aus einem konkreten Grund: Sie wechseln von Lever zu Greenhouse und wollen die Einstellungshistorie von Jahren vollständig übernehmen, eine Übernahme hat zwei Teams auf zwei ATS hinterlassen und das Recruiting muss als eine Einheit arbeiten, oder ein schrittweiser Rollout bedeutet, dass einige Abteilungen schon in Greenhouse leben, während andere ihre offenen Prozesse in Lever zu Ende führen.

In jedem Fall ist die eigentliche Arbeit dieselbe. Lever hält Kandidaten, ihre Opportunities auf bestimmten Stellen, die Stage, in der jede steckt, die Quelle, das Interview-Feedback, den Lebenslauf und das Angebot. Greenhouse erwartet all das als Kandidaten mit Bewerbungen auf Stellen, geführt durch stellenspezifische Stages und echten Greenhouse-Nutzern zugeordnet. Eine Lever-Greenhouse-Anbindung schließt diese Lücke, damit Recruiter keine Pipelines von Hand neu erfassen und kein Kandidat beim Umzug klammheimlich verschwindet.

## Welche Daten fließen

| Objekt / Vorgang in Lever | Wird in Greenhouse zu | Hinweis |
| --- | --- | --- |
| Kandidat | Kandidat | Dedupliziert über E-Mail plus stabile Lever-ID; eine Person, ein Datensatz |
| Opportunity | Bewerbung auf einer Stelle | Levers 1:n-Opportunities werden zu Greenhouse-Bewerbungen zusammengeführt |
| Stelle (Posting) | Stelle / Stellenanzeige | Auf eine bestehende Greenhouse-Stelle abgebildet, neue über die Requisition zugeordnet |
| Stage | Job-Stage | Zuordnung je Stelle - Levers Pipeline-Stages sind nicht Greenhouses Interview-Plan-Stages |
| Quelle / Origin | Source | An Greenhouses Quellen-Taxonomie angeglichen, nicht roh durchgereicht |
| Feedbackformular | Scorecard / Notiz | Strukturiert, wo es passt, als Notiz angehängt, wo nicht |
| Lebenslauf / Datei | Attachment | Aus Lever geladen und neu hochgeladen, nicht per ablaufender URL verlinkt |
| Notiz | Aktivität / Notiz | Autor und Zeitstempel bleiben für die Nachvollziehbarkeit erhalten |
| Angebot (Offer) | Offer | Wo die Harvest-API das Schreiben erlaubt, sonst als Dokument angehängt |
| Nutzer (Recruiter) | Nutzer (On-Behalf-Of) | Auf einen gültigen Greenhouse-Nutzer gemappt, damit Aktionen korrekt zugeordnet sind |

Die Stage-Zuordnung, das Quellen-Mapping und die Nutzerzuordnung stimmen wir einmal zu Beginn ab und hinterlegen sie in der Pipeline. Danach mappt sie niemand mehr von Hand.

## Die Details, an denen einfache Exporte scheitern

Ein CSV-Export aus Lever und ein Massenimport in Greenhouse liefert Ihnen eine Namensliste und sonst wenig. Teuer wird alles, worüber die beiden Datenmodelle uneins sind:

- **Opportunities gegen Bewerbungen.** Ein Lever-Kandidat mit drei Opportunities ist ein Greenhouse-Kandidat mit drei Bewerbungen, nicht drei Kandidaten. Übersieht man das, sät man Greenhouse vom ersten Tag an voller Dubletten und verbringt dann Wochen damit, sie von Hand zusammenzuführen.
- **Stages passen nicht aufeinander.** Lever-Stages sind auf Pipeline-Ebene konfiguriert; Greenhouse-Stages gehören zum Interview-Plan jeder Stelle. Es gibt kein globales Mapping - es ist je Stelle, und ein Kandidat in der falschen Stage überspringt oder wiederholt Interviews.
- **Greenhouse-Schreibregeln.** Die Harvest-API drosselt Schreibzugriffe und verlangt bei Anlage- und Änderungsaufrufen einen On-Behalf-Of-Nutzer. Eine naive Schleife läuft ins Rate-Limit, verliert mitten im Stapel Datensätze oder schreibt jede Aktion einem Service-Account zu. Die Pipeline muss abwarten, wiederholen und den richtigen handelnden Nutzer mitführen.
- **Anhänge laufen ab.** Lebensläufe, die über eine Lever-Download-URL verlinkt sind, lösen sich nicht mehr auf, wenn Greenhouse sie später abrufen will. Dateien müssen während des Laufs geladen und als echte Attachments neu hochgeladen werden.
- **Einwilligung und Diversity-Daten.** AGG- und Diversity-Angaben sind besondere Kategorien personenbezogener Daten. Sie ohne Rechtsgrundlage mitzukopieren ist ein DSGVO-Problem, keine Bequemlichkeit. Was wandert, wird je Feld entschieden, nicht per Voreinstellung.
- **Idempotenz.** Eine Migration, die sich nicht gefahrlos erneut ausführen lässt, ist eine Migration, vor der man Angst hat. Jeder Datensatz braucht einen stabilen Schlüssel, damit ein zweiter Lauf aktualisiert statt dupliziert und ein fehlgeschlagener Stapel genau dort weitermacht, wo er stehen blieb.

## Wie wir sie bauen und betreiben

Wir behandeln das als Pipeline, nicht als einmaliges Skript. Lever-Kandidaten, -Opportunities, -Feedbacks, -Dateien und -Angebote werden über die Lever-API gelesen, validiert, in Ihr abgestimmtes Greenhouse-Mapping überführt und über die Harvest-API geschrieben - mit dem korrekten On-Behalf-Of-Nutzer und einer Wiederhol- und Backoff-Logik, die auf Greenhouses Rate-Limits abgestimmt ist.

Die Pipeline ist idempotent: Jeder Lever-Datensatz trägt eine stabile Kennung, sodass ein erneuter Lauf gegen das abgleicht, was in Greenhouse bereits existiert, statt eine zweite Kopie anzulegen. Sie läuft auf cloud-nativer, vollständig EU-gehosteter AWS-Infrastruktur - Bewerberdaten verlassen die EU nicht, was AVV und DSGVO sauber hält und Ihrem Betriebsrat eine klare Antwort gibt, wo Bewerbungsdaten liegen.

Und dann halten wir sie am Laufen. Bei einer Umstellung heißt das ein überwachter, wiederaufsetzbarer Backfill und ein geprüfter Abgleichsbericht. Beim Parallelbetrieb heißt das laufende Änderungserkennung, Monitoring, Alerting, Incident Response und das Beobachten von API-Änderungen bei Lever und Greenhouse - alles vertraglich bei uns, mit festem Ansprechpartner und SLA.

## Wann sich diese Anbindung lohnt

Wenn Sie ein paar Dutzend aktive Kandidaten umziehen und an historischen Pipelines kein Interesse haben, machen Sie das von Hand oder mit einer Tabelle und dem Massenimport von Greenhouse - und wir sagen Ihnen das auch. Die betreute Pipeline lohnt sich, wenn Sie die Einstellungshistorie von Jahren migrieren, wenn Levers Opportunity-Modell und Greenhouses Job-Stages im großen Stil abzustimmen sind, wenn zwei ATS während eines schrittweisen Rollouts parallel laufen müssen, oder wenn Einwilligung und Bewerberdaten bedeuten, dass der Umzug nachweisbar konform sein muss statt nur ein Kopieren nach bestem Bemühen.

## Häufig gestellte Fragen

### Migrieren Sie uns von Lever nach Greenhouse, oder halten Sie beide Systeme synchron?

Beides ist möglich, aber es sind zwei verschiedene Aufgaben. Eine einmalige Umstellung überträgt Ihre Lever-Historie einmal nach Greenhouse und ist danach fertig. Ein Parallelbetrieb hält beide Systeme abgeglichen, während Teams oder Regionen schrittweise wechseln - das bedeutet Änderungserkennung, Konfliktregeln und ein klares führendes System je Feld. Wir klären vorab, was Sie brauchen, denn die Fehlerbilder sind grundverschieden.

### Wie bringen Sie Levers Opportunity-Modell mit Greenhouses Kandidaten- und Bewerbungsstruktur zusammen?

In Lever kann ein einzelner Kandidat mehrere Opportunities auf verschiedenen Stellen haben; in Greenhouse ist das ein Kandidat mit mehreren Bewerbungen. Wir führen das auf einen Greenhouse-Kandidaten je Person zusammen, verschlüsselt über E-Mail plus eine stabile Lever-ID, und hängen jede Opportunity als Bewerbung an die zugeordnete Stelle. Ohne diese Zusammenführung entstehen Dublettenkandidaten und verwaiste Bewerbungen - der häufigste Weg, auf dem ein roher Import kippt.

### Was passiert mit DSGVO-Daten, Einwilligungen und Diversity- bzw. AGG-Angaben der Bewerber?

Diese Felder werden bewusst behandelt, nicht automatisch mitgeschleift. Angaben zu Herkunft, Geschlecht oder Behinderung sind besondere Kategorien personenbezogener Daten und sollten nach DSGVO und AGG oft gar nicht migriert werden. Wir legen je Feld fest, was wandert, was wegfällt und wie Einwilligung und Löschfristen mitgeführt werden, damit die Greenhouse-Instanz keine Daten erbt, für die keine Rechtsgrundlage mehr besteht.

### Bleiben Interview-Feedback und Scorecards beim Wechsel erhalten?

Teilweise, und wir sagen offen, wo es verlustbehaftet ist. Lever-Feedbackformulare sind eher frei aufgebaut, Greenhouse-Scorecards haben eine feste Form aus Attributen, Bewertungen und einer Gesamtempfehlung. Was sauber passt, bilden wir strukturiert ab; den Rest sichern wir als angehängte Notiz oder Aktivität, statt ihn in Felder zu pressen, in die er nicht gehört. Sie behalten die Bewerbungshistorie, ohne den falschen Eindruck strukturierter Daten, die es nie gab.

### Wer betreibt die Schnittstelle nach dem Go-live, und was ist mit Rate-Limits und API-Änderungen?

Wir. Die Pipeline läuft auf cloud-nativer, vollständig EU-gehosteter Infrastruktur, die wir überwachen, und ist auf Greenhouses Harvest-Schreibdrosselung und die On-Behalf-Of-Pflicht ausgelegt - sie wartet und wiederholt, statt einen Stapel abzubrechen. Ändert Lever oder Greenhouse einen Endpunkt, ist das vertraglich unser Problem. Sie bekommen einen festen Ansprechpartner, Alerting und ein SLA statt eines Migrationsskripts, das sich niemand mehr auszuführen traut.

## Verwandte Integrationen

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

## Nach System

- [Alle Schnittstellen für Greenhouse](https://seamless.engineering/de/integrations/greenhouse/)

## Scoping-Gespräch anfragen

Sie möchten diese Integration umsetzen und dauerhaft betreiben lassen? Sagen Sie uns, welche Systeme verbunden werden sollen und welche Daten fließen müssen. Festpreis-Angebot zur Aufwandsabschätzung innerhalb von 48 Stunden.

- E-Mail: hello@seamless.engineering
- Kontaktformular: https://seamless.engineering/de/#contact