Lever Greenhouse Schnittstelle

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.