Greenhouse BambooHR integration

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.