First-party app
Greenhouse

Greenhouse

Read and write Greenhouse Recruiting data — candidates, applications, jobs, interviews, scorecards and offers — over the Harvest v3 API.

stable Human Resources

About

Greenhouse ships in the w6w first-party pack. It declares 24 actions, 4 health checks, and the host runs its code in a sandbox that never sees the credential.

App id
io.w6w.greenhouse
Version
0.1.4
Author
w6w
Licence
MIT
Categories
Human Resources

Overview

Greenhouse is an applicant tracking system, and this app reads and writes its core recruiting data — candidates, applications, jobs, interviews, scorecards and offers — over Greenhouse’s own Harvest v3 API.

Most of what a workflow needs is one path: find the applications matching a filter, then act on them. This app covers exactly that — creating candidates and their applications, moving an application through pipeline stages, rejecting or hiring it, and filing notes — alongside listing jobs, interviews, scorecards and offers to read the state of a pipeline. Reference lookups for departments, offices, sources, rejection reasons and users let a workflow resolve the real ids Greenhouse’s write endpoints expect rather than guessing labels.

Good for automating candidate intake from a careers page or referral form, moving candidates between pipeline stages based on an external signal such as an assessment result or a scheduling confirmation, syncing interview or offer status into another system, or triggering a rejection notice once a hiring decision is made elsewhere.

Build with Greenhouse

Three routes to the same 24 actions. The Workflow tab is generated from Greenhouse's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.

Create Application

create-application

Add an application or a prospect record for an existing candidate.

Create Candidate

create-candidate

Create a candidate, optionally placing them onto a job as their first application.

Create Note

create-note

Post a note, an activity-feed entry, or a logged e-mail onto a candidate.

Hire Application

hire-application

Mark an application as hired and close the opening it fills.

List Application Stages

list-application-stages

List the stage history of applications — one row per stage entered, with entered/exited timestamps.

List Applications

list-applications

List applications, scoped by candidate, job, job post, source, stage or lifecycle status.

List Attachments

list-attachments

List candidate and application attachments. The returned URLs are signed and short-lived.

List Candidates

list-candidates

List candidates (people), optionally filtered by e-mail, tag, privacy, custom field option or timestamp.

List Departments

list-departments

List departments, optionally scoped to one parent or matched by external id.

List Interviews

list-interviews

List scheduled interviews, scoped by application, job, organiser or status.

List Job Interview Stages

list-job-interview-stages

List the interview stages defined on jobs — the ids a move uses.

List Job Posts

list-job-posts

List job posts, optionally scoped to jobs or boards and filtered by visibility.

List Jobs

list-jobs

List jobs, optionally filtered by status, department, office or requisition id.

List Notes

list-notes

List candidate notes and activity-feed entries, scoped by candidate, application or author.

List Offers

list-offers

List offers, scoped by application, job, candidate or opening.

List Offices

list-offices

List offices, optionally scoped to one parent or matched by external id.

List Openings

list-openings

List the headcount openings on jobs, filtered by job, state or close reason.

List Rejection Reasons

list-rejection-reasons

List rejection reasons — the lookup for the id that Reject Application requires.

List Scorecards

list-scorecards

List interview scorecards, scoped by application, interviewer, submitter or kit.

List Sources

list-sources

List the organisation's candidate sources — the lookup for source_id.

List Users

list-users

List Greenhouse users, optionally filtered by office, department, employee id or e-mail.

Move Application

move-application

Move an application to another stage on the same job, or transfer it to a different job.

Reject Application

reject-application

Reject an application with a reason, optionally sending or scheduling a rejection e-mail.

Update Candidate

update-candidate

Patch a candidate's details. Contact-detail and tag fields replace the whole collection.

A workflow step names the app and the action, and the editor fills in the connection when you pick one. This is the Step shape from the workflow spec, carrying Greenhouse's real ids.

{
  "manifestVersion": "2",
  "name": "greenhouse-example",
  "steps": [
    {
      "id": "create-application",
      "uses": {
        "app": "io.w6w.greenhouse",
        "action": "create-application",
        "connection": "conn_YOUR_CONNECTION_ID"
      },
      "with": {
        "candidateId": "<candidateId>"
      }
    }
  ]
}

Here are some of the things you can do

  • Create Application

    perform
    create-application
  • Create Candidate

    perform
    create-candidate
  • Create Note

    perform
    create-note
  • Hire Application

    perform
    hire-application
  • List Application Stages

    search
    list-application-stages

+19 more actions available

Every app-specific value here is a blank you have to fill in. An app action is reached through the connection that authenticates it, so the address is a connection id, not the app id — and connections belong to your account, so a public page cannot know yours. Create one for Greenhouse, then fill in the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the parameters that action declares. The call itself is real — the shape is transcribed from the studio's own snippet builder, which prints the same kind of blanks — but nothing in it is specific to Greenhouse. The Workflow tab is where this app's real ids are.

Install
npm install @w6w/sdk
yarn add @w6w/sdk
pnpm add @w6w/sdk
deno add npm:@w6w/sdk
Code
import { W6wClient, isActionRun } from "@w6w/sdk";

// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();

const envelope = await client.run({
  urn: "conn_YOUR_CONNECTION_ID",
  action: "create-candidate",
  payload: {
    firstName: "<value>",
    lastName: "<value>",
    // preferredName: "<value>",
    // company: "<value>",
    // title: "<value>",
    // emailAddress: "<value>",
    // emailType: "<value>",
    // phoneNumber: "<value>",
    // phoneType: "<value>",
    // tags: "<value>",
    // jobId: "<value>",
    // sourceId: "<value>",
    // recruiterId: "<value>",
    // coordinatorId: "<value>",
  },
});

if (isActionRun(envelope)) console.log(envelope.value);
Install the CLI
npm install -g @w6w/cli
CLI
w6w run conn_YOUR_CONNECTION_ID --action create-candidate --payload '{"firstName":"<value>","lastName":"<value>"}'

Give an AI agent Greenhouse — without giving it Greenhouse's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.

One tool call
{
  "name": "w6w_invoke",
  "arguments": {
    "ref": "app:io.w6w.greenhouse#create-application",
    "input": {
      "candidateId": "<candidateId>"
    }
  }
}

Every tool names its target with a single ref. The app: form above doesn't name a connection at all — the host resolves which of the caller's Greenhouse connections to sign with, and refuses rather than guesses when the answer is ambiguous.

What the agent gets

Credentials it can't read

The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.

A tool surface scoped to the caller

Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.

A durable workflow in one call

Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.

Health-aware discovery

Greenhouse's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.

The MCP surface is part of the hosted platform. Greenhouse itself is MIT, and the runtime that executes it is source-available (FSL).

Request MCP access

Health checks

Greenhouse declares its own checks, so its health is a property of the app rather than something the host guesses at.

service

Greenhouse platform status

Component status from status.greenhouse.io. The verdict comes from the eleven components inside the Greenhouse Harvest API group; Recruiting, Onboarding, the HRIS links, the third-party integrations and the AWS and Fastly infrastructure are reported alongside them but do not set it.

dependency

Harvest v3 API reachable

Unauthenticated probe of GET /v3/candidates. A schema-correct 401 is a pass — it proves the route exists and Greenhouse is answering. A 404 means the endpoint has been removed, which is the failure a status page cannot report.

quota

Rate-limit headroom

Requests left in the current 30-second window, read from the X-RateLimit-* headers Greenhouse returns on every response.

dependency

This organisation's Harvest silo

Greenhouse's status page reports the Harvest API as eleven independent silos, but publishes no way to learn which one an organisation runs on — so the platform check has to roll all eleven together rather than report yours.