.png)
Greenhouse Integration Guide
Greenhouse integrates with enterprise systems through its Harvest and Job Board REST APIs, selected webhook notifications, and candidate file operations.
Greenhouse integration options at a glance
Greenhouse provides the authenticated Harvest REST API for recruiting data such as Candidates, Jobs, Applications, Offers, Users, and Departments, while the Job Board API supports public job listings and application submission. Selected recruiting events can generate webhook-style notifications, although coverage does not include every object or field change. Candidate-related files and attachments can also be handled through documented API operations. Martini can consume these APIs, receive webhook notifications through a REST endpoint, run scheduled paginated synchronization workflows, transform data, and transfer records or files to downstream systems. Harvest uses API keys with HTTP Basic Authentication and resource-level permissions.
| Integration point | Supported by Greenhouse? | Common use cases | How Martini supports it |
|---|---|---|---|
| Harvest REST API | Yes | Retrieve and, where permitted, create or update Candidates, Jobs, Applications, Offers, Users, Departments, and related recruiting resources. | Martini consumes authenticated REST endpoints in workflows, handles pagination, maps fields, applies business rules, and writes results to downstream systems. |
| Job Board REST API | Yes | Retrieve published jobs and submit applications through public job-board endpoints using a board token. | Martini can call Job Board endpoints from scheduled workflows or expose a controlled API façade for career-site consumers. |
| Webhooks / outbound callbacks | Limited | Receive notifications for selected candidate, application, job, or offer events; coverage does not include every object or field change. | Martini can expose a REST endpoint, validate notifications, apply idempotency, retrieve current Harvest data, and route events. |
| Bulk / async / batch APIs | Limited | Harvest supports paginated reads and resource-specific operations, but a universal bulk mutation or asynchronous batch API is not confirmed. | Martini implements controlled pagination, concurrency limits, checkpoints, and scheduled reconciliation rather than assuming a universal batch endpoint. |
| File / attachment APIs | Yes | Retrieve or transfer candidate resumes, cover letters, and other supported attachments through resource-specific operations. | Martini workflows can handle binary or multipart payloads, preserve metadata, apply security controls, and transfer files downstream. |
| Authentication | Yes | Harvest uses API keys with HTTP Basic Authentication and resource-level permissions; some partner scenarios may use OAuth. | Martini stores credentials in secrets or environment-specific configuration and separates authentication from workflow logic. |
| Database / analytics access | No | No direct Greenhouse customer database interface is confirmed for standard integrations. | Martini uses documented Greenhouse APIs or supported reporting and export mechanisms instead of direct SQL connectivity. |
| SOAP APIs | No | Greenhouse’s documented integration model is REST APIs and selected webhooks rather than SOAP. | Martini should consume the documented REST interfaces and webhook notifications instead of attempting SOAP integration. |
How Greenhouse exposes data and business events
Greenhouse Harvest REST APIs
The Harvest API is Greenhouse’s primary authenticated interface for recruiting and operational data. It supports resource-specific reads and, where permitted, creation or updates for objects such as Candidates, Jobs, Applications, Offers, Users, and Departments. List endpoints are paginated and permissions are assigned to API keys by resource.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates with a protected Harvest API key, retrieves pages or details, maps the Greenhouse model to a canonical or target model, applies business rules, and records synchronization state. The workflow can expose normalized data through a Martini API or write it to downstream applications.
Implementation sequence
Greenhouse Job Board API
The Job Board API uses a board token in the URL and supports public job listings and application submission scenarios. It is distinct from the authenticated Harvest API and is intended for career-site or public portal use cases.
Martini implementation pattern
Martini implementation pattern: a scheduled workflow can cache published Jobs, or a Martini REST API can provide a controlled façade for a website. Martini applies publication, localization, pagination, and caching rules before returning or submitting data.
Implementation sequence
Greenhouse Webhook Notifications
Greenhouse supports webhook-style notifications for selected recruiting events involving areas such as Candidates, Applications, Jobs, or Offers. Event coverage and payload detail depend on configured event types and should not be treated as universal change capture.
Martini implementation pattern
Martini implementation pattern: expose a REST endpoint and receiving workflow, validate the notification according to Greenhouse’s documented mechanism, store an event or source reference for idempotency, then retrieve the current Harvest resource when the notification is incomplete. Scheduled reconciliation covers missed or unsupported changes.
Implementation sequence
Greenhouse Candidate Attachments
Greenhouse supports candidate-related files such as resumes and cover letters through attachment-specific API resources and operations. Transfers may involve binary or multipart requests and require attention to permissions, file size, MIME type, and personal information.
Martini implementation pattern
Martini implementation pattern: a workflow retrieves candidate metadata and supported attachments, validates file properties, optionally scans or transforms the payload, and securely transfers the file and metadata to a document, HR, or onboarding system.
Implementation sequence
Scheduled Harvest Synchronization
Greenhouse synchronization commonly combines paginated API reads with periodic polling because webhook coverage is limited and a general-purpose bulk mutation API is not confirmed. A durable timestamp, cursor, or object state supports incremental reconciliation.
Martini implementation pattern
Martini implementation pattern: a scheduler starts a workflow that retrieves changed resources, controls concurrency, transforms and upserts data, and commits a checkpoint only after successful processing. The same workflow can provide initial backfill and recurring reconciliation.
Implementation sequence
Common Greenhouse integration patterns
Pattern 1: Synchronize Greenhouse applications with an HR platform
When to use this pattern
Use this pattern when recruiting teams need Candidates, Applications, Jobs, and application stages available in an HR or reporting platform. It preserves the distinction between a Candidate and each Application, supports initial backfill, and reconciles changes when webhook coverage is incomplete.
Integration direction
Example Mapping
| Greenhouse Field | Canonical Field | Target Field |
|---|---|---|
| candidate.id | person.externalId | worker.candidateReference |
| application.id | application.externalId | recruitingApplication.id |
| application.status | application.status | recruitingApplication.stage |
| job.id | requisition.externalId | jobRequisition.id |
Martini implementation pattern
A scheduled or webhook-started Martini workflow retrieves the current Harvest resources, validates stage and eligibility rules, maps custom fields, and performs idempotent downstream upserts. It stores both identifiers and uses retries only for transient failures, with reconciliation for missed events.
Martini capabilities used
- workflows
- API consumption
- scheduling
- data mapping
- business rules
- error handling
Pattern 2: Handoff accepted offers to Workday
When to use this pattern
Use this pattern when an accepted Offer or approved application should start a downstream worker or onboarding process. The workflow should prevent duplicate handoffs and minimize exposure of compensation and personal information.
Integration direction
Example Mapping
| Greenhouse Field | Canonical Field | Target Field |
|---|---|---|
| offer.id | offer.externalId | workerOffer.reference |
| candidate.id | person.externalId | worker.candidateReference |
| offer.status | offer.acceptanceStatus | workerOffer.status |
| job.id | position.externalId | workerOffer.positionReference |
Martini implementation pattern
Martini receives a supported Greenhouse event or finds the qualifying Offer during polling, retrieves authoritative details, validates acceptance and handoff status, maps the target payload, and submits an idempotent Workday request. Failures are classified so transient errors can retry without repeating non-idempotent writes.
Martini capabilities used
- webhook receiving
- workflow orchestration
- data mapping
- validation
- business rules
- retry handling
Pattern 3: Publish Greenhouse jobs through a career-site API
When to use this pattern
Use this pattern when a website or portal needs a controlled, normalized view of published Greenhouse Jobs rather than direct access to Greenhouse endpoints. Caching reduces repeated public API requests and allows publication rules to be centralized.
Integration direction
Example Mapping
| Greenhouse Field | Canonical Field | Target Field |
|---|---|---|
| job.id | job.externalId | careerJob.id |
| job.title | job.title | careerJob.title |
| job.location | job.location | careerJob.location |
| job.absolute_url | job.applicationUrl | careerJob.applyUrl |
Martini implementation pattern
Martini consumes the Job Board API using the board token, filters published jobs, maps public fields, and stores or serves the result through a Martini API. Validation, pagination, cache expiry, and upstream error responses are handled centrally.
Martini capabilities used
- API consumption
- API exposure
- scheduling
- data transformation
- validation
- error handling
Pattern 4: Distribute candidate attachments securely
When to use this pattern
Use this pattern when resumes, cover letters, or other supported Candidate files must move to a document repository or downstream HR process. It is appropriate where metadata and binary content must remain correlated and privacy controls are required.
Integration direction
Example Mapping
| Greenhouse Field | Canonical Field | Target Field |
|---|---|---|
| candidate.id | person.externalId | document.subjectId |
| attachment.filename | file.name | document.fileName |
| attachment.content_type | file.mimeType | document.mimeType |
| attachment.created_at | file.createdAt | document.sourceCreatedAt |
Martini implementation pattern
A Martini workflow retrieves attachment metadata and binary content, validates file constraints, applies security and retention rules, and transfers the file with mapped metadata. A durable correlation key prevents duplicate uploads and failed transfers can be replayed safely.
Martini capabilities used
- API consumption
- file handling
- data mapping
- security controls
- idempotency
- error handling
Applications commonly integrated with Greenhouse
Greenhouse data is commonly connected to recruiting, HR, collaboration, identity, document-signature, and background-check applications. Exact capabilities depend on the customer’s Greenhouse configuration, enabled modules, permissions, and partner arrangements.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| LinkedIn Recruiter | Coordinate candidate sourcing and recruiting activity between Greenhouse and LinkedIn workflows. | LinkedIn Recruiter → Martini → Greenhouse | Use REST workflows to normalize candidate and recruiting activity, apply matching rules, and upsert permitted data while retaining Greenhouse identifiers. |
| Checkr | Initiate background checks when a candidate reaches an appropriate recruiting stage and return status information. | Greenhouse → Martini → Checkr | Trigger from a selected Greenhouse event or scheduled poll, validate eligibility, submit the check, and reconcile status updates using idempotent correlation keys. |
| DocuSign | Send offer or employment documents for signature and synchronize signature status. | Greenhouse → Martini → DocuSign | Retrieve permitted Offer data, map recipients and document metadata, invoke the DocuSign API, and process status callbacks or scheduled reconciliation. |
| GoodTime | Coordinate interviews and synchronize candidates, interviews, and availability. | Greenhouse → Martini → GoodTime | Orchestrate Greenhouse API reads and event signals with GoodTime requests, map job and candidate identifiers, and retry transient failures safely. |
| Slack | Notify hiring teams about candidate, interview, approval, or offer activity. | Greenhouse → Martini → Slack | Receive selected Greenhouse notifications, apply routing and privacy rules, and publish concise messages through Slack APIs or supported incoming endpoints. |
| Microsoft Teams | Distribute recruiting notifications and support interview-related collaboration. | Greenhouse → Martini → Microsoft Teams | Use a Martini webhook or polling workflow to transform Greenhouse events into Teams messages, with filtering for departments, jobs, and sensitive fields. |
| Workday | Transfer recruiting or hired-candidate information into the worker lifecycle process. | Greenhouse → Martini → Workday | Validate stage or offer conditions, map candidate and job data to the Workday model, submit the handoff, and retain correlation and reconciliation state. |
| Okta | Support controlled access and, where configured, user lifecycle synchronization for Greenhouse-related applications. | Okta → Martini → Greenhouse | Orchestrate permitted user lifecycle data through APIs, enforce identity and role mapping rules, and record provisioning outcomes without exposing credentials. |
How to build a Greenhouse integration in Martini
Objective
Configure the Greenhouse endpoint and environment-specific credentials without embedding secrets in workflow logic.
Instructions in Martini
- Use the Harvest API key with HTTP Basic Authentication for authenticated recruiting data
- Store the key in Martini secrets or protected environment configuration
- Use the Job Board board token separately for public job-board operations
- Apply least-privilege Greenhouse resource permissions
Objective
Select an event-driven, scheduled, or API-led entry point based on the Greenhouse capability and required freshness.
Instructions in Martini
- Expose a Martini REST endpoint for selected Greenhouse webhook notifications
- Use a scheduler for initial backfills and recurring reconciliation
- Use an API trigger when another system requests current Greenhouse data
- Combine webhooks with polling where event coverage is incomplete
Objective
Obtain the authoritative Greenhouse resource and related objects needed for processing.
Instructions in Martini
- Request Harvest list and detail resources with endpoint-specific pagination
- Retrieve the current resource after a webhook when the payload is incomplete
- Preserve Candidate and Application identifiers separately
- Retrieve attachments through their supported resource operations
Objective
Coordinate Greenhouse calls, transformations, target operations, and durable synchronization state in a maintainable Martini workflow.
Instructions in Martini
- Separate receipt, retrieval, mapping, target writing, and checkpoint logic
- Control concurrency for larger imports
- Route resource types and event types explicitly
- Use a durable store for event references and synchronization state
Objective
Convert Greenhouse recruiting structures into the target model while accommodating customer-specific fields and enumerations.
Instructions in Martini
- Map Candidates, Jobs, Applications, Offers, Users, and Departments explicitly
- Validate required identifiers and stage or status values
- Make custom-field and organizational mappings configurable
- Redact sensitive candidate data from diagnostic output
Objective
Enforce recruiting and privacy rules before downstream writes or notifications.
Instructions in Martini
- Check offer acceptance or application-stage conditions before handoffs
- Filter published versus internal Jobs for public responses
- Prevent duplicate downstream records with correlation keys
- Restrict sensitive compensation, feedback, and personal data to approved targets
Common Greenhouse data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Candidates | Manage people being considered in recruiting processes, including contact and custom-field data. | Workday, Checkr, LinkedIn Recruiter, reporting platforms, document repositories | Martini retrieves Candidates through Harvest, maps configurable fields, preserves identifiers, and applies privacy and deduplication rules. |
| Jobs | Represent open or closed requisitions and associated recruiting configuration. | Career sites, GoodTime, Workday, reporting platforms | Martini synchronizes permitted job details, filters published versus internal jobs, and supports pagination and reconciliation. |
| Applications | Associate a Candidate with a specific Job and track application progress. | HR platforms, recruiting tools, reporting systems | Martini retains both Candidate and Application identifiers, maps stages and sources, and uses idempotent upserts. |
| Offers | Represent employment offers associated with Candidates and Jobs. | Workday, DocuSign, onboarding platforms | Martini applies approval and acceptance rules, restricts sensitive fields, and orchestrates downstream handoffs. |
| Users | Represent recruiters, coordinators, hiring managers, and administrators. | Identity platforms, reporting systems, collaboration tools | Martini synchronizes only permitted user attributes and applies least-privilege and access-control rules. |
| Departments | Organize jobs and recruiting structures by business department. | Workday, reporting platforms, collaboration systems | Martini maps department identifiers to canonical organizational values and validates references during synchronization. |
Authentication and security considerations
Harvest authentication
Greenhouse Harvest uses an API key with HTTP Basic Authentication, with the API key as the username and a blank password. Administrators assign resource-level permissions to the key.
Credential and data protection
- Store API keys and board tokens in protected Martini secrets or environment-specific configuration.
- Use HTTPS and least-privilege Greenhouse permissions.
- Restrict workflow access and redact candidate, offer, compensation, and interview data from logs.
- Apply retention, deletion, and access policies appropriate for personally identifiable information and candidate documents.
Partner authorization
Greenhouse supports OAuth for certain partner and marketplace scenarios, but customer-managed Harvest integrations are more directly documented around API keys and Basic Authentication.
Operational considerations for Greenhouse integrations
Pagination and rate limits
Harvest list endpoints are paginated. Workflows should continue until all pages are processed, detect HTTP 429 responses, honor available response guidance, limit concurrency, and use bounded exponential backoff.
Idempotency and reconciliation
Webhook processing and scheduled polling can overlap. Store event references, object identifiers, timestamps, and downstream correlation keys. Use scheduled reconciliation because webhook coverage is limited to selected events and fields.
Schema and relationship controls
Keep Candidate and Application identifiers separate because one Candidate can have multiple Applications. Make custom fields, stages, departments, offices, sources, and rejection reasons configurable, and test mappings against representative customer data.
Attachments and testing
Candidate files require attention to binary or multipart handling, MIME types, filenames, size limits, secure temporary storage, and duplicate recovery. Test permissions, pagination, rate limits, webhook replay, downstream failures, and API changes before production deployment.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration instead of isolated scripts
Martini provides a structured workflow for receiving Greenhouse notifications, calling Harvest or Job Board APIs, retrieving related resources, transforming data, applying recruiting rules, and writing to multiple targets.
Reusable and maintainable integration logic
Authentication, mappings, validation, pagination, idempotency, retries, and checkpoint handling can be separated from business-specific workflows. This supports initial migration, scheduled reconciliation, and event-driven processing without duplicating scripts.
Controlled APIs and operations
Martini can expose a controlled API façade for career-site or internal consumers while centralizing Greenhouse credentials and privacy controls. Workflow logs, error handling, and deployment configuration provide operational structure for integrations handling sensitive recruiting data.
Frequently asked questions
Greenhouse can be integrated through the authenticated Harvest REST API for recruiting data, the Job Board API for public jobs and application submission, selected webhook-style notifications, scheduled paginated synchronization, and candidate attachment operations. The appropriate combination depends on the required objects, freshness, permissions, and privacy controls.
Yes. Martini can consume Greenhouse Harvest and Job Board REST APIs, receive selected Greenhouse webhook notifications through an exposed REST endpoint, orchestrate scheduled synchronization, map recruiting data, and transfer supported candidate files. No native Martini Greenhouse connector is confirmed in the supplied documentation.
No. A dedicated Greenhouse connector is not required. Martini can use Greenhouse’s confirmed native integration mechanisms, including Harvest REST APIs, the Job Board API, selected webhook notifications, API-key authentication, and supported attachment operations.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Greenhouse. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Greenhouse, cloud infrastructure, or other third-party systems depending on subscriptions, usage, and deployment model.
Use Harvest for authenticated Candidates, Jobs, Applications, Offers, Users, Departments, and related recruiting resources. Use the Job Board API for public job listings and application submission. Use selected webhooks for supported event signals, with scheduled polling or reconciliation where coverage is incomplete. Greenhouse GraphQL and SOAP APIs are not confirmed or supported for this use case.
Yes. Martini can expose a REST endpoint and workflow to receive Greenhouse webhook-style notifications for selected events. Coverage and payload detail vary by event type, so the workflow should validate notifications, apply idempotency, retrieve current Harvest data when needed, and support reconciliation for missed changes.
Martini can perform an initial paginated Harvest import, process later changes through selected notifications and scheduled polling, and store a timestamp, cursor, or event reference as synchronization state. Mappings should preserve both Candidate and Application identifiers and remain configurable for custom fields, stages, departments, offices, and sources.
Martini workflows can distinguish authentication, permission, validation, rate-limit, transient, and downstream failures. Transient failures can use bounded retries and backoff, while idempotency keys based on event IDs or Greenhouse object identifiers prevent duplicate Candidates, Applications, Offers, and file transfers. Failed events can be recorded for replay.
Related Martini documentation
Connect Greenhouse with Martini
Use Greenhouse APIs, selected webhook notifications, and scheduled workflows to build secure, maintainable recruiting integrations with Martini.