> ## Documentation Index
> Fetch the complete documentation index at: https://docs.guild.ai/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> To act on a user's behalf in Guild, use the Guild REST API at https://api.guild.ai/v1.
> The OpenAPI spec is unauthenticated: https://docs.guild.ai/openapi.json (or openapi.yaml).
> Authenticate with an account API key, sent as HTTP Basic (key id as username, secret as password) or as `Authorization: Bearer <api_key_id>:<api_key_secret>`. See https://docs.guild.ai/api-reference/introduction#authentication.
> To run one agent on demand without account-wide access, use an API trigger instead: https://docs.guild.ai/platform/api-triggers.
> To act on Guild from an MCP client, connect to https://api.guild.ai/mcp (OAuth) or run `guild mcp` locally. Setup: https://docs.guild.ai/api-reference/mcp.
> To search these docs from an MCP client, connect to https://docs.guild.ai/mcp. The full page index is https://docs.guild.ai/llms.txt.

# Read candidates, jobs, and scorecards from Greenhouse in Guild agents

> Connect Guild agents to the Greenhouse Harvest v3 API with a client ID and secret or an access token, to read candidates, jobs, and scorecards and add notes.

Integrations · Greenhouse

Guild agents read Greenhouse candidates, applications, jobs, openings, interviews, and scorecards, and add notes to candidates through the Harvest v3 API. Guild stores your Greenhouse credentials and injects them server-side, so agent code never sees them. Credential policies decide which Greenhouse operations each agent may call.

> [card] [Book a demo](https://guild-ai.cal.com/gtm/meeting-with-guild.ai)
>
> See how teams govern agents that use Greenhouse.

> [card] [Talk to sales](https://guild.ai/talk-to-sales)
>
> Get access to Guild, then connect Greenhouse to your first agent.

## What the Greenhouse integration exposes

Both Greenhouse integrations call Harvest v3 at `https://harvest.greenhouse.io/v3`, Greenhouse's replacement for the retired v1 and v2 APIs. Tools cover candidates, applications, jobs, openings, offices, departments, interviews, scorecards, users and their job permissions, custom fields, approval flows, notes, attachments, and tags.

## Choose an integration

Harvest v3 authenticates with short-lived OAuth access tokens issued by the client credentials grant. The two integrations have the same tools and differ in who gets those tokens.

| | Greenhouse (OAuth) | Greenhouse (access token) |
| - | - | - |
| Integration | `guildai~greenhouse-oauth2` | `guildai~greenhouse` |
| You connect | A Harvest v3 client ID and client secret | An access token you requested yourself |
| Token refresh | Guild requests a new token before the current one expires | None. Requests fail when the token expires, until you reconnect a new one |
| Tools | `greenhouse_oauth2_` prefix, from `GreenhouseOauth2Tools` | `greenhouse_` prefix, from `GreenhouseTools` |
| Use for | Agents in production, including ones that run unattended | A quick test with a token you already have |

Use **Greenhouse (OAuth)** unless you have a reason not to.

## How it works

**1. Create Harvest v3 credentials**

In Greenhouse, create a Harvest v3 custom integration and note its client ID and client secret. Grant only the permissions the agent needs.

**2. Connect them in Guild**

Go to **Access & setup > Credentials**, click **Connect**, select **greenhouse-oauth2**, and enter the **Client ID** and **Client Secret**. Guild exchanges them for an access token at `https://auth.greenhouse.io/token` and keeps it current.

**3. Import the tools you need**

Import `GreenhouseOauth2Tools` from `@guildai-services/guildai~greenhouse-oauth2` and use `pick()` to give the agent only the tools its job needs.

## Why Greenhouse access needs governing

Greenhouse holds candidate personal data, and the integration can also edit and delete applications, users, and permissions. Guild keeps your credentials server-side and checks every request against your [credential policies](https://docs.guild.ai/platform/credential-policies.md). A sourcing agent can read candidates and add notes while a DENY rule blocks every delete and user change.

## Authentication

### Greenhouse (OAuth)

* **Type:** OAuth M2M, client credentials grant
* **Token endpoint:** `https://auth.greenhouse.io/token`, with the client ID and secret sent as HTTP Basic authentication
* **Header:** Guild sends the current access token as `Authorization: Bearer <token>`

### Greenhouse (access token)

* **Type:** API key
* **Header:** Guild sends the token as `Authorization: Bearer <token>`

Request the token yourself with the client credentials grant, then select **greenhouse** under **Access & setup > Credentials** and paste `access_token` from the response into **API Key**:

```bash theme={null}
curl -s -X POST https://auth.greenhouse.io/token \
  -u "<client ID>:<client secret>" \
  -d grant_type=client_credentials
```

When the token expires, requests return `401` until you request a new one and reconnect it.

See [Credentials](https://docs.guild.ai/platform/credentials.md) for workspace, member, and agent-scoped credentials.

## Usage

```typescript theme={null}
import { GreenhouseOauth2Tools } from "@guildai-services/guildai~greenhouse-oauth2"
import { llmAgent, pick } from "@guildai/agents-sdk"

export default llmAgent({
  systemPrompt: "You summarize interview feedback for each open application on a job.",
  tools: {
    ...pick(GreenhouseOauth2Tools, [
      "greenhouse_oauth2_get_jobs",
      "greenhouse_oauth2_get_applications",
      "greenhouse_oauth2_get_scorecards",
      "greenhouse_oauth2_post_notes",
    ]),
  },
})
```

The integration has more than 170 tools, so pick the ones the agent needs rather than spreading the whole set. With the access-token integration, import `GreenhouseTools` from `@guildai-services/guildai~greenhouse` and drop `oauth2_` from each tool name, such as `greenhouse_get_jobs`.

## Tools

Tools in the latest published version of `guildai~greenhouse-oauth2`. The access-token integration has the same tools with the `greenhouse_` prefix.

> [accordion] All 177 tools
>
> | Tool | What it does |
> | - | - |
> | `greenhouse_oauth2_delete_applications_id` | Permanently delete a single application, along with its interview stages, scorecards, rejection details, and prospect details. |
> | `greenhouse_oauth2_delete_applied_candidate_tags_id` | Detach a single tag from a candidate. |
> | `greenhouse_oauth2_delete_attachments_id` | Permanently remove an attachment from its application. |
> | `greenhouse_oauth2_delete_blocked_spam_sources_bulk` | Removes multiple blocked spam sources in a single request, identified by id. |
> | `greenhouse_oauth2_delete_blocked_spam_sources_id` | Removes a blocked spam source. |
> | `greenhouse_oauth2_delete_candidate_educations_id` | Remove a single education entry from a candidate's profile. |
> | `greenhouse_oauth2_delete_candidate_employments_id` | Remove a single employment entry from a candidate's profile. |
> | `greenhouse_oauth2_delete_candidates_id` | Permanently delete a candidate and all of their applications, attachments, scorecards, notes, and other associated records. |
> | `greenhouse_oauth2_delete_candidate_tags_id` | Remove a tag from your organization's candidate-tag dictionary. |
> | `greenhouse_oauth2_delete_custom_field_departments_id` | Remove a department from a custom field's visibility scope. |
> | `greenhouse_oauth2_delete_custom_field_offices_id` | Remove an office from a custom field's visibility scope. |
> | `greenhouse_oauth2_delete_custom_field_options_bulk` | Asynchronously archive many options at once by id. |
> | `greenhouse_oauth2_delete_custom_field_options_id` | Archive a custom field option so it can no longer be selected on new records. |
> | `greenhouse_oauth2_delete_custom_fields_id` | 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… |
> | `greenhouse_oauth2_delete_future_job_permissions_id` | Revoke a single future job permission by id. |
> | `greenhouse_oauth2_delete_interviews_id` | Cancel and delete a scheduled interview. |
> | `greenhouse_oauth2_delete_job_hiring_managers_id` | Unassign a hiring manager from a job by deleting the join row. |
> | `greenhouse_oauth2_delete_job_notes_id` | Permanently delete a job note. |
> | `greenhouse_oauth2_delete_job_owners_id` | Remove a user from the hiring team in one role by deleting the join row. |
> | `greenhouse_oauth2_delete_job_post_locations_id` | Detach a single location from a job post. |
> | `greenhouse_oauth2_delete_openings_bulk` | Asynchronously remove many openings in a single call. |
> | `greenhouse_oauth2_delete_openings_id` | Permanently remove an opening from its job. |
> | `greenhouse_oauth2_delete_user_job_permissions_id` | Revoke a single user job permission by id, removing that user's Job Admin role on the job. |
> | `greenhouse_oauth2_get_ai_opt_out_statuses` | A candidate's decision to opt out of AI-assisted review (Talent Matching) for a specific job. |
> | `greenhouse_oauth2_get_applications` | Applications represent a candidate's journey on a specific job — the bridge between a candidate (person) and a job. |
> | `greenhouse_oauth2_get_application_stages` | 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. |
> | `greenhouse_oauth2_get_applied_candidate_tags` | Applied candidate tags are the join rows between candidates and the organization's candidate-tag dictionary — one row per (candidate, tag) pair. |
> | `greenhouse_oauth2_get_approval_flows` | Approval flows are the multi-step approval definitions attached to a job or to a candidate's offer. |
> | `greenhouse_oauth2_get_approver_groups` | Approver groups are the ordered tiers of approvers inside a single approval flow on a job or offer. |
> | `greenhouse_oauth2_get_approvers` | Approvers are the individual users assigned to approve a job, offer, or other approvable resource. |
> | `greenhouse_oauth2_get_attachments` | Attachments are files associated with an application — resumes, cover letters, take-home tests, offer documents, e-signed agreements, and other supporting documents. |
> | `greenhouse_oauth2_get_blocked_spam_sources` | Lists the IP addresses, CIDR ranges, email addresses, and email domains the organization has blocked from submitting applications. |
> | `greenhouse_oauth2_get_bulk_requests` | Bulk requests track the asynchronous bulk operations submitted to Harvest V3. |
> | `greenhouse_oauth2_get_bulk_requests_bulk_action_uuid` | Retrieve a single bulk request, including the per-row success and failure result files. |
> | `greenhouse_oauth2_get_candidate_attribute_types` | 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… |
> | `greenhouse_oauth2_get_candidate_educations` | Candidate educations are the school/degree/discipline entries on a candidate's profile — one row per education entry. |
> | `greenhouse_oauth2_get_candidate_employments` | Candidate employments are the work history entries on a candidate's profile — one row per employer/title the candidate has held. |
> | `greenhouse_oauth2_get_candidates` | Candidates are the people your organization is recruiting — both active applicants and prospects. |
> | `greenhouse_oauth2_get_candidate_tags` | Candidate tags are the org-wide library of tag names available to apply to candidates (e.g. `engineering`, `referral`, `2026-grad`). |
> | `greenhouse_oauth2_get_close_reasons` | 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`). |
> | `greenhouse_oauth2_get_custom_field_departments` | 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. |
> | `greenhouse_oauth2_get_custom_field_offices` | 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. |
> | `greenhouse_oauth2_get_custom_field_options` | 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`. |
> | `greenhouse_oauth2_get_custom_fields` | Custom fields are the org-defined dictionary of structured data your organization layers onto core resources — jobs, offers, openings, candidates, applications, and users. |
> | `greenhouse_oauth2_get_default_interviewers` | Default interviewers are the users pre-selected as the interview panel for a specific stage on a job. |
> | `greenhouse_oauth2_get_demographic_answer_options` | Demographic answer options are the selectable choices on a `demographic_question`. |
> | `greenhouse_oauth2_get_demographic_answers` | 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… |
> | `greenhouse_oauth2_get_demographic_questions` | 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… |
> | `greenhouse_oauth2_get_demographic_question_sets` | 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… |
> | `greenhouse_oauth2_get_departments` | Departments are the organizational units jobs are assigned to (e.g. `Engineering`, `Marketing`). |
> | `greenhouse_oauth2_get_eeoc` | 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… |
> | `greenhouse_oauth2_get_email_templates` | Email templates are reusable subject/body pairs your organization uses to communicate with candidates, prospects, and the hiring team. |
> | `greenhouse_oauth2_get_focus_candidate_attributes` | 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… |
> | `greenhouse_oauth2_get_future_job_permissions` | Future job permissions grant a 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… |
> | `greenhouse_oauth2_get_interviewers` | Interviewers are the panel members on actual scheduled interviews — each row pairs one interview with one user (or, for external attendees, one email address). |
> | `greenhouse_oauth2_get_interviewer_tags` | 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… |
> | `greenhouse_oauth2_get_interview_kits` | 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… |
> | `greenhouse_oauth2_get_interview_media` | Interview media contains recordings and transcripts created by Greenhouse AI notetaking. |
> | `greenhouse_oauth2_get_interviews` | 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… |
> | `greenhouse_oauth2_get_job_board_custom_locations` | Job board custom locations are the curated list of location strings a site admin maintains for posting jobs to a given job board. |
> | `greenhouse_oauth2_get_job_boards` | 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… |
> | `greenhouse_oauth2_get_job_candidate_attributes` | 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. |
> | `greenhouse_oauth2_get_job_hiring_managers` | 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… |
> | `greenhouse_oauth2_get_job_interviews` | 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… |
> | `greenhouse_oauth2_get_job_interview_stages` | Interview stages are the steps of a job's interview plan — for example `Application Review`, `Phone Screen`, `Onsite`, and `Offer`. |
> | `greenhouse_oauth2_get_job_notes` | Job notes are free-form, organization-internal notes attached to a job (the requisition). |
> | `greenhouse_oauth2_get_job_owners` | 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. |
> | `greenhouse_oauth2_get_job_post_locations` | 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… |
> | `greenhouse_oauth2_get_job_posts` | Job posts are the candidate-facing listings of a job. |
> | `greenhouse_oauth2_get_job_post_searchable_locations` | 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)… |
> | `greenhouse_oauth2_get_jobs` | Jobs are the open requisitions and hiring plans your organization is recruiting against. |
> | `greenhouse_oauth2_get_notes` | List notes on candidate profiles, including logged emails and activity feed entries. |
> | `greenhouse_oauth2_get_offers` | Offers are the formal job offers extended to a candidate's application. |
> | `greenhouse_oauth2_get_offices` | 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… |
> | `greenhouse_oauth2_get_openings` | Openings are the individual headcount slots beneath a job — one opening per seat you intend to hire for. |
> | `greenhouse_oauth2_get_pay_input_ranges` | 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. |
> | `greenhouse_oauth2_get_pay_inputs` | Pay inputs are the individual compensation components (e.g. `Base Salary`, `Sign-on Bonus`, `Equity`) that make up a Greenhouse pay transparency rule. |
> | `greenhouse_oauth2_get_prospect_details` | 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… |
> | `greenhouse_oauth2_get_prospect_pools` | 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. |
> | `greenhouse_oauth2_get_prospect_pool_stages` | 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… |
> | `greenhouse_oauth2_get_referrers` | 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… |
> | `greenhouse_oauth2_get_rejection_details` | 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… |
> | `greenhouse_oauth2_get_rejection_reasons` | 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`… |
> | `greenhouse_oauth2_get_rejection_reasons_id` | Retrieve a single rejection reason by id. |
> | `greenhouse_oauth2_get_scorecard_candidate_attributes` | 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. |
> | `greenhouse_oauth2_get_scorecard_question_answer_options` | 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`… |
> | `greenhouse_oauth2_get_scorecard_question_answers` | A scorecard question answer is one interviewer's response to a single question on a scorecard. |
> | `greenhouse_oauth2_get_scorecard_question_candidate_attributes` | Scorecard question candidate attributes are the join that tells an interviewer which focus attributes a given scorecard question is asking them to assess. |
> | `greenhouse_oauth2_get_scorecard_question_options` | Scorecard question options are the multiple-choice values shown to interviewers for `single_select` and `multi_select` `scorecard_questions`. |
> | `greenhouse_oauth2_get_scorecard_questions` | Scorecard questions are the prompts configured on an `interview_kit` that interviewers answer when submitting a scorecard. |
> | `greenhouse_oauth2_get_scorecards` | 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. |
> | `greenhouse_oauth2_get_sources` | 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… |
> | `greenhouse_oauth2_get_tracking_links` | Tracking links are unique short URLs (e.g. `https://grnh.se/`) that an organization shares to attribute candidates to a `source` — campaign URLs, referral links, employee outreach, social posts, and… |
> | `greenhouse_oauth2_get_user_emails` | User emails are the email addresses attached to a Greenhouse user. |
> | `greenhouse_oauth2_get_user_job_permissions` | User job permissions are the per-user, per-job access grants that pair a user with a Job Admin role on a specific job. |
> | `greenhouse_oauth2_get_user_roles` | User roles are the organization-wide dictionary of access levels a user can hold — the categories themselves, not the per-user assignments. |
> | `greenhouse_oauth2_get_users` | Users are the Greenhouse accounts inside your organization — recruiters, hiring managers, interviewers, coordinators, sourcers, and site admins. |
> | `greenhouse_oauth2_patch_applications_id` | Patch attribution and metadata fields on an existing application (source, referrer, recruiter, coordinator, prospect pool/stage, rejection date, custom fields). |
> | `greenhouse_oauth2_patch_approval_flows_id` | 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). |
> | `greenhouse_oauth2_patch_blocked_spam_sources_bulk` | Updates the `note` on multiple blocked spam sources in a single request. |
> | `greenhouse_oauth2_patch_blocked_spam_sources_id` | Updates the `note` on a blocked spam source. `source_type` and `value` are immutable on this endpoint — to change either, delete the entry and create a new one. |
> | `greenhouse_oauth2_patch_candidates_id` | Patch an existing candidate's profile fields. |
> | `greenhouse_oauth2_patch_candidates_id_anonymize` | Anonymize selected categories of personally identifiable data on a candidate (for GDPR, CCPA, or other right-to-be-forgotten requests). |
> | `greenhouse_oauth2_patch_custom_field_options_bulk` | 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. |
> | `greenhouse_oauth2_patch_custom_field_options_id` | Edit the display label, sort order, or external id of an existing custom field option. |
> | `greenhouse_oauth2_patch_custom_fields_id` | Edit the definition of an existing custom field. `field_type` and `value_type` are immutable — to change either, create a new field. |
> | `greenhouse_oauth2_patch_departments_bulk` | Asynchronously update many departments in a single request. |
> | `greenhouse_oauth2_patch_departments_id` | Update an existing department's name, `external_id`, or position in the department tree. |
> | `greenhouse_oauth2_patch_interviews_id` | Patch a scheduled interview's time, location, video conferencing link, external calendar event id, or interviewer panel. |
> | `greenhouse_oauth2_patch_job_notes_id` | Update an existing job note. |
> | `greenhouse_oauth2_patch_job_posts_id` | Edit a job post in place — change its public title, replace its HTML body, or transition its publication status between `draft` and `live`. |
> | `greenhouse_oauth2_patch_jobs_id` | Patch an existing job's editable fields. |
> | `greenhouse_oauth2_patch_offers_id` | Patch fields on an existing offer. |
> | `greenhouse_oauth2_patch_offices_bulk` | Update up to the bulk-endpoint cap of offices in a single request. |
> | `greenhouse_oauth2_patch_offices_id` | Update an existing office. |
> | `greenhouse_oauth2_patch_openings_bulk` | 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`… |
> | `greenhouse_oauth2_patch_openings_id` | Patch an existing opening's editable fields, or change its status. |
> | `greenhouse_oauth2_patch_rejection_details_id` | Patch the rejection reason or rejection question custom field answers on a rejected application without changing its `rejected_at` timestamp. |
> | `greenhouse_oauth2_patch_scorecard_candidate_attributes_id` | Update one candidate attribute rating on a scorecard. Deprecated; prefer updating the scorecard. |
> | `greenhouse_oauth2_patch_scorecard_question_answers_id` | Update one answer on a scorecard. Deprecated; prefer updating the scorecard. |
> | `greenhouse_oauth2_patch_scorecards_id` | Patch an existing scorecard. |
> | `greenhouse_oauth2_patch_users_bulk` | Update up to the bulk-endpoint cap of users in a single request. |
> | `greenhouse_oauth2_patch_users_id` | Patch an existing user's profile fields. |
> | `greenhouse_oauth2_post_applications` | Create a new application for an existing candidate. |
> | `greenhouse_oauth2_post_applications_id_convert_to_candidate` | Promote a prospect application to a candidate application on a specific job. `job_id` is required and the prospect must already be associated with that job (or attached at the prospect pool level). |
> | `greenhouse_oauth2_post_applications_id_hire` | Mark an application as hired and close out the matching opening on the job. |
> | `greenhouse_oauth2_post_applications_id_move` | Advance the candidate to a new interview stage. `from_stage_id` is required and must match the candidate's current stage — it acts as a guard against stale move requests. |
> | `greenhouse_oauth2_post_applications_id_reject` | Reject an application and record the reason. `rejection_reason_id` is required (look up valid reasons via `GET /v3/rejection_reasons`); optional `notes` capture context on the rejection. |
> | `greenhouse_oauth2_post_applications_id_unreject` | Reverse a rejection, putting the application back into the in-process state on the stage it was rejected from. |
> | `greenhouse_oauth2_post_applied_candidate_tags` | Apply an existing tag to a candidate. |
> | `greenhouse_oauth2_post_approval_flows` | Create a multi-step approval flow on a job (and optionally a specific offer), seeded with the supplied approver groups. |
> | `greenhouse_oauth2_post_approval_flows_id_request_approvals` | Start an existing `pending` approval flow by emailing its initial approver(s) and recording who requested the approvals. |
> | `greenhouse_oauth2_post_attachments` | Attach a file to an existing application. |
> | `greenhouse_oauth2_post_blocked_spam_sources` | Adds a new IP address, CIDR range, email address, or email domain to the organization's spam blocklist. |
> | `greenhouse_oauth2_post_blocked_spam_sources_bulk` | Adds multiple blocked spam sources in a single request, typically used to sync the blocklist from an external security tool. |
> | `greenhouse_oauth2_post_candidate_educations` | Add a new education entry to a candidate's profile. `candidate_id` is required; school, degree, and discipline are optional but must reference existing custom-field option ids (look these up via \`GET… |
> | `greenhouse_oauth2_post_candidate_employments` | Add a new work history entry to a candidate's profile. `candidate_id`, `company_name`, `title`, and `start_date` are required; `company_name` and `title` are free-text strings (no custom-field option… |
> | `greenhouse_oauth2_post_candidates` | Create a new candidate profile in your organization. `first_name` and `last_name` are required; all other profile fields are optional. |
> | `greenhouse_oauth2_post_candidates_bulk` | Asynchronously create many candidate profiles in a single call, typically for HRIS sync workflows that create a batch of candidates at once. |
> | `greenhouse_oauth2_post_candidates_id_merge` | Merge two candidate profiles by collapsing the candidate identified by `secondary_candidate_id` into the candidate at `{id}`. |
> | `greenhouse_oauth2_post_candidate_tags` | Add a new tag to your organization's candidate-tag dictionary. `name` is required and must be unique within the organization (case sensitive); creating a tag with an existing name returns a 422. |
> | `greenhouse_oauth2_post_custom_field_departments` | Restrict a custom field's visibility to one additional department. |
> | `greenhouse_oauth2_post_custom_field_offices` | Restrict a custom field's visibility to one additional office. |
> | `greenhouse_oauth2_post_custom_field_options` | Add a new selectable value to a `single_select` or `multi_select` custom field. |
> | `greenhouse_oauth2_post_custom_field_options_bulk` | Asynchronously add many options at once, typically for HRIS sync workflows that replace or extend a dropdown's option set in a single pass. |
> | `greenhouse_oauth2_post_custom_fields` | Add a new custom field to your organization's dictionary. `name`, `field_type`, and `value_type` are required. |
> | `greenhouse_oauth2_post_departments` | Create a department in the caller's organization. |
> | `greenhouse_oauth2_post_future_job_permissions` | Grant a user a Job Admin role on future jobs matching an optional department and/or office scope. |
> | `greenhouse_oauth2_post_interviews` | Schedule an interview against a candidate's application at a specific slot on the job's interview plan. `application_id`, `job_interview_id` (the interview-plan slot), `starts_at`, `ends_at`, and… |
> | `greenhouse_oauth2_post_job_hiring_managers` | Assign a user as a hiring manager on a job. |
> | `greenhouse_oauth2_post_job_notes` | Create a free-form note attached to a job. |
> | `greenhouse_oauth2_post_job_owners` | Add a user to a job's hiring team as a `recruiter`, `sourcer`, or `coordinator`. |
> | `greenhouse_oauth2_post_job_post_locations` | Attach a location to an existing `job_post`. |
> | `greenhouse_oauth2_post_job_posts` | Create a new job post by duplicating an existing one. |
> | `greenhouse_oauth2_post_jobs` | Create a new job from an existing template. `template_job_id` and `number_of_openings` are required; the template supplies the interview plan, scorecards, hiring team, and approval workflow, since… |
> | `greenhouse_oauth2_post_jobs_bulk` | Asynchronously create many jobs in a single call, typically for HRIS sync workflows that open a batch of requisitions at once. |
> | `greenhouse_oauth2_post_notes` | Create a candidate note, log an email, or record an activity-feed entry on a candidate. `note_type` selects which: `NOTE` posts to the Notes tab, `EMAIL` logs an email into the activity feed (and… |
> | `greenhouse_oauth2_post_offers` | Create a new offer on an existing application. `application_id` is always required; `starts_on` and `custom_fields` (compensation components plus any offer custom fields configured on the hiring… |
> | `greenhouse_oauth2_post_offices` | Create a new office for the organization. |
> | `greenhouse_oauth2_post_openings` | Add a new headcount slot to an existing job. `job_id` is required; `opening_id` is an optional partner-supplied external identifier (e.g. an HRIS or ATS position id) and `custom_fields` set values on… |
> | `greenhouse_oauth2_post_openings_bulk` | 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. |
> | `greenhouse_oauth2_post_scorecard_candidate_attributes` | Add a candidate attribute rating to a scorecard. Deprecated; prefer updating the scorecard. |
> | `greenhouse_oauth2_post_scorecard_question_answer_options` | Select options for a scorecard question answer. Deprecated; prefer updating the scorecard. |
> | `greenhouse_oauth2_post_scorecard_question_answers` | Add an answer to a scorecard. Deprecated; prefer updating the scorecard. |
> | `greenhouse_oauth2_post_scorecards` | Create a scorecard for a given interview kit on a given application. `interview_kit_id`, `interviewer_id`, `interviewed_at`, `application_id`, and `submitter_id` are required; the kit must belong to… |
> | `greenhouse_oauth2_post_user_emails` | Attach an additional email address to a Greenhouse user — the V3 replacement for V1 `POST /users/{id}/email_addresses`. |
> | `greenhouse_oauth2_post_user_job_permissions` | Grant a user a Job Admin role on a single job. |
> | `greenhouse_oauth2_post_users` | Create a new Greenhouse user in your organization. `first_name`, `last_name`, and `primary_email` are required; the user is created with the Basic permission level and no job assignments. |
> | `greenhouse_oauth2_post_users_activate_bulk` | Reactivate up to the bulk-endpoint cap of users in a single request. |
> | `greenhouse_oauth2_post_users_bulk` | Create up to the bulk-endpoint cap of users in a single request. |
> | `greenhouse_oauth2_post_users_deactivate_bulk` | Deactivate up to the bulk-endpoint cap of users in a single request. |
> | `greenhouse_oauth2_post_users_id_activate` | Reactivate a previously deactivated user so they can sign in to Greenhouse and be assigned to new jobs again. |
> | `greenhouse_oauth2_post_users_id_deactivate` | Deactivate a Greenhouse user. |
> | `greenhouse_oauth2_post_users_id_revoke_permissions` | Demote a Site Admin to a Basic user, removing their organization-wide access. |
> | `greenhouse_oauth2_post_users_revoke_permissions_bulk` | Demote up to the bulk-endpoint cap of site admins to Basic users in a single request. |
> | `greenhouse_oauth2_put_approval_flows_id_replace_approver_groups` | 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. |
> | `greenhouse_oauth2_put_approver_groups_id_replace_approver` | Swap one approver in an approver group for another user without rebuilding the rest of the approval flow — the V3 replacement for V1 \`PUT… |

## Frequently asked questions

> [accordion] Can I use a Harvest v1 or v2 API key?
>
> No. Both integrations call Harvest v3 only. Greenhouse retired v1 and v2 on August 31, 2026.

> [accordion] Why does the agent start getting 401 errors?
>
> With **greenhouse-oauth2**, check that the client ID and secret are still valid in Greenhouse, then reconnect them. With **greenhouse**, the access token expired: request a new one and reconnect it, or switch to **greenhouse-oauth2**.

> [accordion] Can a new application trigger a Guild agent?
>
> Not yet. Guild doesn't receive Greenhouse webhooks, so you can't create an event trigger for Greenhouse. Run the agent on a [schedule](https://docs.guild.ai/platform/schedule-triggers.md) instead.

## Related

**Also runs on Guild:** [Ashby](https://docs.guild.ai/integrations/ashby.md)

**Read:** Docs: [Credential policies](https://docs.guild.ai/platform/credential-policies.md) · [Credentials](https://docs.guild.ai/platform/credentials.md) · [Tools in agents](https://docs.guild.ai/sdk/tools.md)