Greenhouse 400 "stage_id is not valid for this job" when the agent advances a candidate to a deleted stage

Greenhouse 400 "stage_id is not valid for this job" on candidate advance

TL;DR

The stage the agent is moving the candidate to was deleted or belongs to a different job, so the move is rejected. Fix: fetch the current stage list for the job from the API, resolve the target stage by name to a live ID, and refresh the cached stage map. Never hardcode stage IDs.

Error

400 Bad Request
"stage_id is not valid for this job"

Steps

1. List the live stages: GET /v1/jobs/[JOB_ID]/stages. Expected: 200 with the current stage IDs and names; the agent's target ID is absent or renamed.

2. Find the intended stage by name in the live list and take its current ID. Expected: a valid stage_id for this job.

3. Retry the move with the live ID via the application's advance or move endpoint. Expected: 200 or 201; the candidate lands in the right stage.

4. Replace any hardcoded stage IDs in the agent with a resolve-by-name step against the live stage list, cached briefly. Expected: the next stage rename or deletion degrades to a lookup miss, not a 400.

5. Add handling for the lookup miss: alert the team instead of guessing a nearby stage. Expected: a human picks the right stage when plans change.

Use this when

• stage moves 400 after interview plans were edited
• the agent caches stage IDs
• jobs were cloned or rebuilt
• the stage exists but on a different job

Not for this skill when

• the error is 403 (that is the on-behalf-of permissions problem)
• the stage list call itself 404s (check the job ID)
• the move succeeds but the UI shows the old stage (that is stale cache, not a 400)

Variant phrasings

• "Greenhouse stage_id invalid for job"
• "stage deleted Greenhouse API move candidate"
• "advance candidate 400 Harvest API"
• "stage ID not valid"

Why it happens

Greenhouse stages belong to a specific job's interview plan. When recruiters edit the plan, old stage IDs die and new ones are born, but the agent's cached map still points at the corpse. The API validates the stage against the job, so a stale or cross-job ID is rejected.

Edge cases

• Cloned jobs get fresh stage IDs even with identical names; re-resolve per job.
• Some stages are milestone-only and cannot be moved into via API; check the stage's properties.
• If two stages share a name, resolve by name plus order, not name alone.
• Keep the cache TTL short (minutes, not days) during active hiring.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AGEmWxwBydyVRYd8bpI9Eg