Greenhouse
Let hires follow jobs, applications, candidates and scorecards in Greenhouse, add notes and move candidates between stages, with candidates' personal data kept to a minimum.
Explore 7 actions and their permissionsExact inputs, sign-in scopes, access limits and approval rules.
With Greenhouse connected, a hire can:
- list jobs and their stages,
- list applications by job, status or recent activity,
- read a candidate (through one of their applications) and their interview scorecards,
- add a note to a candidate's record, for the hiring team,
- move an application to another stage, asking a person first when it's an offer or hired stage,
- be woken when applications to its jobs have new activity.
Hires never message candidates, and never reject or archive anyone: people do that in Greenhouse.
Candidates' personal data: the minimum, unless you widen it
- By default a hire sees a candidate's name and their applications (job, stage, status). Roster asks Greenhouse for nothing more.
- More fields hires may see (ordinary):
company,title,tags. - Sensitive fields hires may see (only if a hire's job needs them):
emails,phones,links,addresses, andprivateNotes(scorecards' private notes). A sensitive field typed in the ordinary list is refused, so it always takes a deliberate second step. - Scorecard notes are shown with email addresses and phone numbers taken out.
- Hires are told that personal data stays inside your team.
1. Make API credentials in Greenhouse
Straight there: Greenhouse's API credentials (sign in if asked).
Greenhouse's API signs in with OAuth (its older API keys stopped working in August 2026).
- In Greenhouse, open Configure → Dev Center → API Credentials and click Create new API
credentials. Choose Harvest V3 (OAuth) and name them
Roster. - Allow only what hires need: listing jobs, job interview stages, applications, candidates and scorecards, and, for hires that write, creating notes and moving applications.
- Copy the client ID and client secret.
- Find the ID of the Greenhouse user hires should act as (ideally one named for your team, like
Bayt Studio Hiring): hires see what that user sees, and notes appear as theirs.
2. Connect it in Roster
- Open Integrations → Tools → Add a tool, search for Greenhouse and choose it.
- Client ID and Client secret: paste them.
- Act as user: the user's ID from step 1. Left empty, hires act as the integration's own user, which sees your whole organisation.
- More fields hires may see and Sensitive fields hires may see: leave them empty unless a hire's job needs more.
- Click Connect.
Roster checks the key when you click Connect. Once it's accepted, the connection shows Connected as your Greenhouse account, and the user hires act as. If it's refused, Roster says what to fix (a mistyped key, a missing permission) and saves nothing.
3. Give hires access
On the hire's Tools tab, click Give access on Greenhouse:
- Read only: it can list jobs, stages and applications, and read candidates and scorecards.
- Read and write: it can also add notes and move applications between stages. Moving someone to an offer or hired stage always asks a person first: the hire asks in the thread, and when the approver says yes, Roster moves exactly that application, once.
- Jobs: job titles or IDs whose candidates it may see and work on. Leave it empty for every job. Candidates for any other job are refused, even if the hire knows their application.
Watching applications
A hire's responsibility can watch Greenhouse: it's woken when applications to its jobs are new or have activity.
Tools and permissions reference
This reference is built from the same definitions Roster uses to connect Greenhouse and give hires access. It updates with each release.
Authentication and requested permissions
The account or app you connect sets the outer limit. Each hire's access can narrow it further. Connecting a tool gives it to no hire until you give access on that hire's Tools tab.
OAuth client credentials
From Greenhouse's Dev Center: API Credentials, type Harvest V3 (OAuth).
When making a key, use these permissions from the connection guide:
- Jobs, job interview stages, applications, candidates, scorecards: list
- Notes: create, applications: move (hires that write)
Connection fields
| Field | What to provide |
|---|---|
Client IDclientIdOptional | From Greenhouse's Dev Center: API Credentials, type Harvest V3 (OAuth). |
Client secretclientSecretOptional · sealed secret | Use the value for your account or connection. |
Act as useruserIdOptional | The ID of the Greenhouse user hires act as: they see what that user sees, and notes are theirs. Use one named for your team. Empty: the integration's own user, which sees everything. |
More fields hires may seemoreFieldsOptional | By default hires see only candidates' names and their applications (job, stage, status). Add ordinary fields here by their name, like company, title, tags, source. Sensitive ones go in the next list. |
Sensitive fields hires may seesensitiveFieldsOptional | Only if a hire's job needs them: pay, identity numbers, birth dates, home addresses, private contact details, notes. Like emails, phones, links, privateNotes. Leave empty unless you mean it. |
Per-hire limits
Read-only hires receive only actions that read. Read-and-write access also allows actions that change things, where the connection itself permits them. An empty resource allowlist usually means everything the connected account can reach; each field below explains its meaning.
| Field | What to provide |
|---|---|
JobsjobsOptional | Job titles or IDs whose candidates it may see and work on. Leave empty for every job. |
Actions
7 actions: 5 only read and 2 change something. A read action may still need approval when your workspace or hire is set to ask. A locked approval requirement always applies.
7 of 7 actions. Open an action for its arguments and full input schema.
list_jobsRead only
Jobs in Greenhouse this hire may work on, open ones unless asked.
Approval: Uses your workspace and hire approval settings.
| Argument | Type | Details |
|---|---|---|
allOptional | boolean | include closed and draft jobsDefault: false |
Full input schema (JSON)
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"all": {
"default": false,
"description": "include closed and draft jobs",
"type": "boolean"
}
}
}list_stagesRead only
A job's stages in Greenhouse, in order, for move_stage.
Approval: Uses your workspace and hire approval settings.
| Argument | Type | Details |
|---|---|---|
jobRequired | string | the job's ID or title |
Full input schema (JSON)
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"job": {
"type": "string",
"minLength": 1,
"maxLength": 200,
"description": "the job's ID or title"
}
},
"required": [
"job"
]
}list_applicationsRead only
Applications in Greenhouse, most recently active first: by job, status (active, hired, rejected…) or activity since a time.
Approval: Uses your workspace and hire approval settings.
| Argument | Type | Details |
|---|---|---|
jobOptional | string | the job's ID or title |
statusOptional | "active" | "hired" | "rejected" | "archived" | See input schema below. |
changedSinceOptional | string | See input schema below. |
limitOptional | integer | See input schema below.Default: 20 |
Full input schema (JSON)
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"job": {
"description": "the job's ID or title",
"type": "string",
"minLength": 1,
"maxLength": 200
},
"status": {
"type": "string",
"enum": [
"active",
"hired",
"rejected",
"archived"
]
},
"changedSince": {
"type": "string",
"format": "date-time",
"pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"
},
"limit": {
"default": 20,
"type": "integer",
"minimum": 1,
"maximum": 50
}
}
}get_candidateRead only
A candidate in Greenhouse, through one of their applications: their name, the fields this connection allows, and their applications to jobs this hire may see. Only the fields this connection allows are shown; personal data stays inside your team, so don't repeat it outside.
Approval: Uses your workspace and hire approval settings.
| Argument | Type | Details |
|---|---|---|
applicationRequired | string | the application's ID, from list_applications |
Full input schema (JSON)
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"application": {
"type": "string",
"minLength": 1,
"maxLength": 64,
"description": "the application's ID, from list_applications"
}
},
"required": [
"application"
]
}list_feedbackRead only
Interview feedback (scorecards) on an application in Greenhouse: who, when, their overall rating and their answers. Contact details in the text are taken out.
Approval: Uses your workspace and hire approval settings.
| Argument | Type | Details |
|---|---|---|
applicationRequired | string | the application's ID, from list_applications |
Full input schema (JSON)
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"application": {
"type": "string",
"minLength": 1,
"maxLength": 64,
"description": "the application's ID, from list_applications"
}
},
"required": [
"application"
]
}add_noteRead and write
Add a note to a candidate's record in Greenhouse, for the hiring team. The candidate never sees it.
Approval: Uses your workspace and hire approval settings.
| Argument | Type | Details |
|---|---|---|
applicationRequired | string | the application's ID, from list_applications |
textRequired | string | See input schema below. |
Full input schema (JSON)
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"application": {
"type": "string",
"minLength": 1,
"maxLength": 64,
"description": "the application's ID, from list_applications"
},
"text": {
"type": "string",
"minLength": 1,
"maxLength": 10000
}
},
"required": [
"application",
"text"
]
}move_stageRead and write
Move an application to another stage of its job in Greenhouse (list_stages names them). Moving to an offer or hired stage waits for a person's approval: Roster asks in the thread and moves it, once, when they approve. Rejecting or archiving isn't done here: people do that in Greenhouse.
Approval: when it moves someone to an offer or hired stage.
| Argument | Type | Details |
|---|---|---|
applicationRequired | string | the application's ID, from list_applications |
stageRequired | string | the stage's name or ID |
candidateRequired | string | the candidate's name, as list_applications shows it; checked |
Full input schema (JSON)
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"application": {
"type": "string",
"minLength": 1,
"maxLength": 64,
"description": "the application's ID, from list_applications"
},
"stage": {
"type": "string",
"minLength": 1,
"maxLength": 200,
"description": "the stage's name or ID"
},
"candidate": {
"type": "string",
"minLength": 1,
"maxLength": 200,
"description": "the candidate's name, as list_applications shows it; checked"
}
},
"required": [
"application",
"stage",
"candidate"
]
}Watches and incoming events
- This integration supports a responsibility that watches for changes. The guide above explains what it checks and how to limit it.
- No incoming webhook handler is declared for this integration.
Limits and troubleshooting
- Permission errors: check both the connected account's rights and the hire's resource and read/write limits.
- Expired or revoked access: reconnect or replace the key on the connection.
- Rate limits and unavailable services can interrupt work. The hire's timecard records the outcome.
- The action schema describes accepted inputs. It does not grant additional access or bypass approvals.