# Greenhouse BambooHR integration

*Greenhouse → BambooHR*

**In short:** A Greenhouse to BambooHR integration turns each accepted hire in your applicant tracking system into a ready-to-onboard employee record in your HRIS. When a candidate reaches the Hired stage with a resolved offer, the pipeline reads the candidate, offer, job, department, office, and start date from the Greenhouse Harvest API and creates a BambooHR employee with the correct job information, compensation, and status. Done properly it is not a nightly CSV export: it is an event-driven, idempotent pipeline that maps values to BambooHR's managed lists, never creates a duplicate on a re-fired webhook, and deliberately leaves diversity and EEOC data behind in Greenhouse.

## What a Greenhouse to BambooHR integration actually does

Greenhouse knows everything about how someone got hired - the job they applied to, the interviews, the approved offer with its start date and salary, the office and department they were recruited into. BambooHR needs a much narrower slice of that, but it needs it correct and on time: a clean employee record with the right job information, the right compensation, and a status that lets onboarding, payroll, and access provisioning begin on day one.

The gap between the two is manual re-keying. Someone in People Operations opens the accepted offer in Greenhouse, opens BambooHR in another tab, and types the new hire in by hand - usually the week before they start, usually under time pressure. A Greenhouse to BambooHR integration closes that gap: when a candidate is genuinely hired, the pipeline reads the offer from Greenhouse and creates the BambooHR employee record for you, mapped to your HRIS conventions.

## What data moves

| Greenhouse object / event | Becomes in BambooHR | Notes |
| --- | --- | --- |
| Candidate reaches Hired stage | New employee record | Triggered on the hire event, not on earlier stage moves |
| Candidate profile | Name, personal + work email, phone | Only the fields onboarding actually needs |
| Resolved offer - start date | Hire date | Offer must be approved and resolved first |
| Resolved offer - compensation | Compensation row (pay rate, pay type, pay per, currency) | Mapped to BambooHR's pay-schedule and currency enumerations |
| Job / role | Job title | From the Greenhouse job, not the free-text req name |
| Department & office | Division, Department, Location | Crosswalked to BambooHR's managed lists |
| Employment type | Employment status (full-time, part-time, contract) | Agreed mapping per your BambooHR setup |
| Scorecards, EEOC, rejection reasons | Deliberately not synced | Recruiting-only data stays in Greenhouse |

The exact field mapping, the department and location crosswalk, and which BambooHR custom fields receive which offer values are agreed once and encoded in the pipeline. After that, nobody re-types a hire.

## The details that break naive exports

A CSV export or a generic connector gets you the easy 80% and leaves the expensive, error-prone 20% on your desk:

- **There is no shared key.** A Greenhouse candidate ID means nothing to BambooHR, and email is not a reliable join - candidates apply with personal addresses, employees get a work address on day one. Without a stored mapping between the Greenhouse candidate and application and the BambooHR employee, every re-run risks a duplicate person.
- **BambooHR lists are strict.** Division, Department, and Location are managed values, not free text. An offer that says "Berlin" or "Sales - DACH" has to resolve to the exact BambooHR entries or the write fails or, worse, silently creates a junk value.
- **Hired is not the same as offer resolved.** Greenhouse lets a candidate sit at the Hired stage before the offer is approved. Read too early and you get no start date and no salary. The trigger has to wait for a resolved offer.
- **Compensation is structured, not a number.** BambooHR wants a pay rate, a pay type (salary or hourly), a pay period, a currency, and an effective date. A single salary figure from an offer custom field has to be decomposed into all of those correctly, including currency for a multi-country DACH team.
- **Rate limits and partial failures.** The Greenhouse Harvest API is rate limited, and creating an employee in BambooHR is several calls - the record, then job information, then compensation. If the third call fails, you must not leave a half-created employee behind. The pipeline sequences these and rolls forward cleanly on retry.

## How we build and run it

We treat this as an event-driven pipeline, not a batch job. A Greenhouse hire event (or a short poll of recently hired candidates as a safety net) is validated, the offer and job are pulled from the Harvest API, values are crosswalked to your BambooHR conventions, and a complete employee record is written in the correct order.

The pipeline is idempotent: the mapping between the Greenhouse candidate and application ID and the BambooHR employee ID means a re-fired webhook or a manual re-run updates the existing person instead of creating a duplicate. It runs on cloud-native, fully EU-hosted AWS infrastructure, so candidate and employee data never leaves the EU - which keeps the AVV / DPA and your GDPR obligations clean, and keeps recruiting-only personal data out of the HRIS by design.

And then we keep it running. Monitoring, alerting, incident response, and - critically - watching for Greenhouse and BambooHR API changes are our responsibility under contract. You get a named owner and an SLA. A new hire appearing in BambooHR stops depending on someone remembering to do it.

## When this integration is worth building

If you hire a few people a quarter, a manual entry is genuinely fine and we will tell you so. The integration earns its place when hiring volume is steady, when new starters must be in BambooHR on time for payroll cut-off and IT provisioning, when you run multiple departments, offices, or currencies that make the field mapping fiddly, or when People Ops keeps losing a morning to re-keying offers that a pipeline should have delivered correctly in the first place.

## Frequently asked questions

### What actually triggers a record being created in BambooHR?

The accepted hire, not merely moving a candidate through stages. We listen for the candidate reaching your Hired milestone in Greenhouse with a resolved, approved offer attached. Only then do we have a real start date and compensation to write. A candidate marked hired without a signed offer is held back until the offer resolves, so BambooHR never gets a half-built record.

### Will it create duplicate employees if the hire event fires twice?

No. Greenhouse webhooks can and do re-fire, and someone can re-run a sync. We keep a mapping between the Greenhouse candidate and application ID and the BambooHR employee ID, so a repeated event updates the same record rather than creating a second one. Rehires are handled explicitly against your BambooHR rehire policy instead of silently minting a new person.

### Does candidate diversity, EEOC, or interview feedback flow into BambooHR?

No, and that is deliberate. Scorecards, EEOC or diversity self-identification, and rejection reasons stay in Greenhouse. BambooHR only receives the fields an HRIS legitimately needs to onboard and pay someone - name, contact details, job, department, location, start date, and compensation. Keeping recruiting-only personal data out of the HRIS is part of the GDPR scoping we agree up front.

### How do you map Greenhouse departments and offices to BambooHR?

BambooHR treats Division, Department, and Location as managed lists with exact values, so free-text from a Greenhouse offer will not just slot in. We agree the crosswalk once - which Greenhouse department and office maps to which BambooHR division, department, and location - and encode it in the pipeline. Anything that does not match a known value is flagged rather than written blind.

### Who operates it after go-live?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor. If Greenhouse or BambooHR changes an API field or an auth flow, that is our problem to fix, not something your People team discovers when a Monday-morning hire fails to appear. You get a named owner, alerting, and an SLA rather than a script someone has to remember to run.

## Related integrations

- [Greenhouse ↔ Workday](https://seamless.engineering/integrations/greenhouse-workday/): Greenhouse Workday integration
- [Lever ↔ Greenhouse](https://seamless.engineering/integrations/lever-greenhouse/): Lever Greenhouse integration
- [Workable ↔ BambooHR](https://seamless.engineering/integrations/workable-bamboohr/): Workable BambooHR integration
- [BambooHR ↔ Workday](https://seamless.engineering/integrations/bamboohr-workday/): BambooHR Workday integration
- [HiBob ↔ BambooHR](https://seamless.engineering/integrations/hibob-bamboohr/): HiBob BambooHR integration
- [Personio ↔ LinkedIn](https://seamless.engineering/integrations/personio-linkedin/): Personio LinkedIn integration

## Browse by system

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

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