Greenhouse MCP server for your AI

Create a new application for an existing candidate.

Mark an application as hired and close out the matching opening on the job.

Applications represent a candidate's journey on a specific job, the bridge between a candidate (person) and a job.

Users are the Greenhouse accounts inside your organization, recruiters, hiring managers, interviewers, coordinators, sourcers, and site admins.

Advance the candidate to a new interview stage.

Search applications through Greenhouse's full-text candidate search index, returning the same application shape as GET /v3/applications with richer pipeline filters (job status, department, office, hiring team, candidate tag, stage outcome, etc.).

Reverse a rejection, putting the application back into the in-process state on the stage it was rejected from.

Patch attribution and metadata fields on an existing application (source, referrer, recruiter, coordinator, prospect pool/stage, rejection date, custom fields).

Create a new candidate profile in your organization.

Candidates are the people your organization is recruiting, both active applicants and prospects.

Search candidates through Greenhouse's full-text candidate search index, returning the same candidate shape as GET /v3/candidates with richer pipeline filters (job, stage, recruiter, coordinator, source, candidate tag, prospect pool, etc.).

Patch an existing candidate's profile fields.

Everything about one candidate in one call: profile, every application with its job and stage, recent notes, scorecards, interviews and the list of files.

Read a file on a candidate: a resume, cover letter, take-home test or offer document.

Read the row-by-row results of a finished bulk job, to see which rows failed and why.

Fetch ONE Greenhouse record by id: a candidate, application, job, offer, scorecard, interview, user, note or any other resource.

See how a job's hiring is going: each interview stage in order, how many active candidates sit in it, and who has had no activity for stalled_days (default 14), oldest first.

Openings are the individual headcount slots beneath a job, one opening per seat you intend to hire for.

Move a candidate's application to another stage of the same job, by stage name, or to the next stage if you name none.

Reject a candidate's application with a reason given by name.

Jobs are the open requisitions and hiring plans your organization is recruiting against.

Search jobs by free-text term, returning the same job shape as GET /v3/jobs with hiring-team and custom-field filters (assigned user and role, department, office, external posting, custom field answer, templates).

Patch an existing job's editable fields.

Record an interview that is already scheduled on an external calendar against a candidate's application at a specific slot on the job's interview plan.

Create a candidate note, log an email, or record an activity-feed entry on a candidate.

Departments are the organizational units jobs are assigned to (e.g. Engineering, Marketing).

Interviews are scheduled interview events on a candidate's application, each row pairs an application with a slot on the job's interview plan (the job_interview) and carries the start/end time, location, organizer, video conferencing link, and lifecycle status.

Notes are free-form entries on a candidate's profile, candidate notes, logged emails, system activity, interview feedback, and other entries that appear in the candidate activity feed.

Offices are the organization's recruiting locations (e.g. San Francisco, New York, Remote (US)) and the foundational scoping unit for jobs, candidates, custom-field visibility, and pay-range display.

Patch a scheduled interview's time, location, video conferencing link, external calendar event id, or interviewer panel.

Apply an existing tag to a candidate.

Attach a file to an existing application.

Attachments are files associated with an application, resumes, cover letters, take-home tests, offer documents, e-signed agreements, and other supporting documents.

Candidate tags are the org-wide library of tag names available to apply to candidates (e.g. engineering, referral, 2026-grad).

Job posts are the candidate-facing listings of a job.

Offers are the formal job offers extended to a candidate's application.

Scorecards are the per-interview evaluations that interviewers fill out: overall recommendation, key takeaways, private and public notes, and ratings on the interview kit's focus attributes.

Patch fields on an existing offer.

Rejection reasons are the organization-defined dictionary of outcomes recorded when an application is rejected (e.g. Not a cultural fit, Lacking skill(s)/qualification(s), Wasn't interested, Didn't like offer, Spam).

Application stages are the rows that make up a candidate's stage history on an application, one row per interview stage the application has occupied, with entered_at and exited_at timestamps.

Interview stages are the steps of a job's interview plan, for example Application Review, Phone Screen, Onsite, and Offer.

Sources are the organization-defined dictionary of channels through which candidates enter the pipeline, job boards (e.g. LinkedIn, Indeed), agencies, referrals, internal applicants, prospecting tools, events, and other ways an application is attributed.

Read one department on a public job board, with its published jobs.

Read one published job post as candidates see it.

Read a public job board's name and intro text, as candidates see it.

Read one office on a public job board, with its published jobs.

Read one prospect post section of a public job board.

List the degrees an application form offers.

List a public job board's departments with the jobs published in each.

List the disciplines an application form offers.

List the jobs published on a public job board, as candidates see them.

List a public job board's offices with the jobs published in each.

List the schools an application form offers.

List the prospect post sections of a public job board.

Submit an application to a published job post, the way the careers page does.

Reactivate a previously deactivated user so they can sign in to Greenhouse and be assigned to new jobs again.

Reactivate up to the bulk-endpoint cap of users in a single request.

Create up to the bulk-endpoint cap of users in a single request.

Deactivate up to the bulk-endpoint cap of users in a single request.

Move many applications between stages, or to other jobs, in a single request.

Demote up to the bulk-endpoint cap of site admins to Basic users in a single request.

Update up to the bulk-endpoint cap of users in a single request.

Promote a prospect application to a candidate application on a specific job.

Create a new Greenhouse user in your organization.

Deactivate a Greenhouse user.

Permanently delete a single application, along with its interview stages, scorecards, rejection details, and prospect details.

Reject an application and record the reason.

Demote a Site Admin to a Basic user, removing their organization-wide access.

Patch an existing user's profile fields.

Anonymize selected categories of personally identifiable data on a candidate (for GDPR, CCPA, or other right-to-be-forgotten requests).

Asynchronously create many candidate profiles in a single call, typically for HRIS sync workflows that create a batch of candidates at once.

Permanently delete a candidate and all of their applications, attachments, scorecards, notes, and other associated records.

Merge two candidate profiles by collapsing the candidate identified by secondary_candidate_id into the candidate at {id}.

Adds multiple blocked spam sources in a single request, typically used to sync the blocklist from an external security tool.

Asynchronously add many options at once, typically for HRIS sync workflows that replace or extend a dropdown's option set in a single pass.

Asynchronously add many openings across one or more jobs in a single call, typically for HRIS sync workflows that open or extend headcount on a batch of requisitions.

Removes multiple blocked spam sources in a single request, identified by id.

Asynchronously archive many options at once by id.

Asynchronously remove many openings in a single call.

Updates the note on multiple blocked spam sources in a single request.

Asynchronously edit the label, sort order, or external id of many options in one call, most often used to reorder a dropdown after an upstream HRIS reshuffle or to rename options en masse.

Asynchronously patch many openings in a single call, commonly for HRIS integrations that close batches of headcount with status: "closed" and close_reason_id, or reconcile partner opening_id values after a sync.

Adds a new IP address, CIDR range, email address, or email domain to the organization's spam blocklist.

Add a new selectable value to a single_select or multi_select custom field.

Add a new headcount slot to an existing job.

Removes a blocked spam source.

Archive a custom field option so it can no longer be selected on new records.

Permanently remove an opening from its job.

Lists the IP addresses, CIDR ranges, email addresses, and email domains the organization has blocked from submitting applications.

Custom field options are the selectable values on a single_select or multi_select custom field, each row belongs to exactly one custom field via custom_field_id.

Updates the note on a blocked spam source.

Edit the display label, sort order, or external id of an existing custom field option.

Patch an existing opening's editable fields, or change its status.

Asynchronously create many jobs in a single call, typically for HRIS sync workflows that open a batch of requisitions at once.

Create a multi-step approval flow on a job (and optionally a specific offer), seeded with the supplied approver groups.

Create a new job from an existing template.

Approval flows are the multi-step approval definitions attached to a job or to a candidate's offer.

Wholesale-replace the ordered tiers of approvers on an existing approval flow, the V3 equivalent of rebuilding the flow's structure from an external HRIS.

Start an existing pending approval flow by emailing its initial approver(s) and recording who requested the approvals.

Toggle whether an existing approval flow is sequential (approver groups resolve one at a time in sort_order) or parallel (all groups activate at once).

Asynchronously grant Job Admin roles on specific jobs to many users in a single call.

Asynchronously update many departments in a single request.

Update up to the bulk-endpoint cap of offices in a single request.

Add a new custom field to your organization's dictionary.

Create a department in the caller's organization.

Create a free-form note attached to a job.

Create a new office for the organization.

Grant an user a Job Admin role on a single job.

Permanently delete a custom field from your organization's dictionary, along with all stored values on parent records (jobs, offers, candidates, applications, etc.) and any associated custom_field_options.

Cancel and delete a scheduled interview.

Permanently delete a job note.

Permanently delete a candidate note.

Revoke a single user job permission by id, removing that user's Job Admin role on the job.

Custom fields are the org-defined dictionary of structured data your organization layers onto core resources, jobs, offers, openings, candidates, applications, and users.

Job notes are free-form, organization-internal notes attached to a job (the requisition).

User job permissions are the per-user, per-job access grants that pair an user with a Job Admin role on a specific job.

Edit the definition of an existing custom field.

Update an existing department's name, external_id, or position in the department tree.

Update an existing job note.

Update a candidate note.

Update an existing office.

Add a new education entry to a candidate's profile.

Add a new work history entry to a candidate's profile.

Add a new tag to your organization's candidate-tag dictionary.

Restrict a custom field's visibility to one additional department.

Restrict a custom field's visibility to one additional office.

Grant an user a Job Admin role on future jobs matching an optional department and/or office scope.

Assign an user as a hiring manager on a job.

Add an user to a job's hiring team as a recruiter, sourcer, or coordinator.

Create a new job post by duplicating an existing one.

Attach a location to an existing job_post.

Create a new offer on an existing application.

Create a scorecard for a given interview kit on a given application.

Detach a single tag from a candidate.

Permanently remove an attachment from its application.

Remove a single education entry from a candidate's profile.

Remove a single employment entry from a candidate's profile.

Remove a tag from your organization's candidate-tag dictionary.

Remove a department from a custom field's visibility scope.

Remove an office from a custom field's visibility scope.

Revoke a single future job permission by id.

Unassign a hiring manager from a job by deleting the join row.

Remove an user from the hiring team in one role by deleting the join row.

Detach a single location from a job post.

Applied candidate tags are the join rows between candidates and the organization's candidate-tag dictionary, one row per (candidate, tag) pair.

Candidate educations are the school/degree/discipline entries on a candidate's profile, one row per education entry.

Candidate employments are the work history entries on a candidate's profile, one row per employer/title the candidate has held.

A custom_field_department restricts a custom field's visibility to a single department, so the field only appears on jobs, offers, or candidates whose department matches.

A custom_field_office restricts a custom field's visibility to a single office, so the field only appears on jobs, openings, or offers whose office matches.

Future job permissions grant an user a Job Admin role on jobs that don't exist yet, when a new job is created in the matching department and/or office, the permission automatically assigns the user that role on the job.

Job hiring managers are users designated as hiring managers on a job, typically the subject-matter expert for the role who reviews candidates in the Hiring Manager Review stage and receives notifications about new applicants.

Job owners are the recruiters, sourcers, and coordinators on a job's hiring team, the users who own sourcing, recruiting, and scheduling work for the role.

Job post locations are the join rows that attach one or more locations to a job_post, a multi-location posting (e.g. San Francisco, Remote (US), New York on a single role) has one row per location.

Edit a job post in place, change its public title, replace its HTML body, or transition its publication status between draft and live.

Patch an existing scorecard.

Create a referrer that has no Greenhouse user account, such as an outside referrer, so applications can be credited to them.

Attach an additional email address to a Greenhouse user, the V3 replacement for V1 POST /users/{id}/email_addresses.

Retrieve a single bulk request, including the per-row success and failure result files.

Retrieve a single rejection reason by id.

Approver groups are the ordered tiers of approvers inside a single approval flow on a job or offer.

Bulk requests track the asynchronous bulk operations submitted to Harvest V3.

Referrers are the people credited with bringing a candidate into the pipeline, typically employees making referrals, but also agency recruiters, LinkedIn recruiters, or any other party captured under "Who Gets Credit" on a candidate's application.

Rejection details are the per-application rejection records, one row per rejected application, capturing who rejected it, when, why (the rejection reason), the linked rejection note, and any answers to the organization's rejection question custom fields.

User emails are the email addresses attached to a Greenhouse user.

Swap one approver in an approver group for another user without rebuilding the rest of the approval flow, the V3 replacement for V1 PUT /v1/approval_flows/{id}/approver_groups/{id}/replace_approver.

Patch the rejection reason or rejection question custom field answers on a rejected application without changing its rejected_at timestamp.

A candidate's decision to opt out of AI-assisted review (Talent Matching) for a specific job.

Approvers are the individual users assigned to approve a job, offer, or other approvable resource.

Read the audit log: who changed or looked at what in Greenhouse in the last 30 days.

Candidate attribute types are the structured attribute dictionary on a job, the per-job catalogue of evaluable traits (e.g. JavaScript, Leadership, Years of experience) that get rated on scorecards and that AI matching uses to score candidate fit.

Close reasons are the organization-defined dictionary of outcomes recorded when an opening is closed (e.g. Hire - New Headcount, Hire - Backfill, On Hold, Not Filling).

Default interviewers are the users pre-selected as the interview panel for a specific stage on a job.

Demographic answer options are the selectable choices on a demographic_question.

Demographic answers are individual applicant submissions to the organization's voluntary demographic questions on a job post, distinct from the federally-mandated EEOC questionnaire, which has its own resource.

Demographic question sets are named groupings of demographic_questions an organization attaches to a job post or candidate survey to collect self-reported applicant demographic data (e.g. for DE&I reporting).

Demographic questions are the voluntary self-identification prompts applicants see on job posts and candidate surveys (separate from the EEOC questionnaire, which carries its own legally-mandated wording).

EEOC responses capture a candidate's voluntary self-identification of race, gender, veteran status, and disability status, collected via the federally-approved Equal Employment Opportunity Commission questionnaire.

Email templates are reusable subject/body pairs your organization uses to communicate with candidates, prospects, and the hiring team.

Focus candidate attributes are the subset of a job's job_candidate_attributes that an individual interview kit elevates as focus areas, the attributes Greenhouse highlights at the top of the interviewer's scorecard so they know which traits to prioritize for that interview.

Interview kits are the per-job, per-slot evaluation packets interviewers see when conducting an interview, the instructions, exercises, scorecard questions, and focus attributes attached to one slot on one job's interview plan.

Interview media contains recordings and transcripts created by Greenhouse AI notetaking.

Interviewer tags are organization-defined labels assigned to interviewer users, such as "Bar Raiser," "Diversity Trained," or "Senior." They are surfaced as Interviewer Groups in the Greenhouse UI and used by schedulers to narrow the pool of interviewers when selecting one for a stage.

Interviewers are the panel members on actual scheduled interviews, each row pairs one interview with one user (or, for external attendees, one email address).

Job board custom locations are the curated list of location strings a site admin maintains for posting jobs to a given job board.

A job board is a destination an organization publishes job posts to, either the organization's single internal board (visible only to signed-in employees) or one of its external boards (public careers site, embedded iFrame, or syndicated integration).

Job candidate attributes are the per-job instances of a job's candidate_attribute_types, one row for each evaluable trait (e.g. JavaScript, Leadership) configured on a specific job.

Job interviews are the interview slots configured on a job's interview plan, the template definitions that say, for example, "this job's Onsite stage has a 30-minute recruiter chat, a 45-minute hiring manager interview, and a take-home test." Each slot belongs to a job_interview_stage on a specific job and carries the default name, duration, scheduling type, and scorecard requirement.

Searchable locations are the individual geographic locations attached to a job post, one row per location, each with a formatted display string plus its component city, region (state/province), postal code, county, country, and latitude/longitude.

Pay input ranges are the per-job-post minimum and maximum values for a pay component (e.g. base salary, bonus) referenced by a pay transparency rule.

Pay inputs are the individual compensation components (e.g. Base Salary, Sign-on Bonus, Equity) that make up a Greenhouse pay transparency rule.

A prospect detail is the per-prospect record that captures where a candidate sits in the CRM: which prospect pool and stage they currently occupy, who owns them, and the department/office they are being considered for.

Prospect pool stages are the smaller buckets inside a prospect pool that recruiters use to track where each passive prospect sits in their nurture process, for example Not Reviewed, In Discussion, or Keep Warm - Senior.

A prospect pool is an organization-defined collection of prospects (candidates not yet attached to a specific job), typically used to manage talent communities and sourcing pipelines.

Scorecard candidate attributes are the per-scorecard ratings an interviewer captured on each focus attribute, what they thought of this candidate on each attribute on this scorecard.

Scorecard question answer options are the join rows between a scorecard question answer and the option(s) selected for it, one row per (scorecard_question_answer_id, scorecard_question_option_id) pair.

A scorecard question answer is one interviewer's response to a single question on a scorecard.

Scorecard question candidate attributes are the join that tells an interviewer which focus attributes a given scorecard question is asking them to assess.

Scorecard question options are the multiple-choice values shown to interviewers for single_select and multi_select scorecard_questions.

Scorecard questions are the prompts configured on an interview_kit that interviewers answer when submitting a scorecard.

Tracking links are unique short URLs (e.g. https://grnh.se/<token>) that an organization shares to attribute candidates to a source, campaign URLs, referral links, employee outreach, social posts, and third-party board placements.

User roles are the organization-wide dictionary of access levels an user can hold, the categories themselves, not the per-user assignments.