Greenhouse Harvest API 404 for a candidate ID that exists i

Not specified by the original author.

Greenhouse Harvest 404: candidate ID vs application ID confusion

TL;DR

The ID in the Greenhouse UI URL is usually the application ID, not the candidate ID, so /v1/candidates/[that ID] 404s even though the person exists. Fix: resolve the application first, read its candidate_id, then call the candidates endpoint with that. Applications and candidates are different resources with different IDs.

Error

404 Not Found
GET /v1/candidates/[ID] - the ID exists in the Greenhouse UI

Steps

1. Take the UI ID and try it as an application: GET /v1/applications/[ID]. Expected: 200 with the application record, confirming it is an application ID.

2. Read candidate_id from that application record. Expected: the real candidate ID, different from the UI number.

3. Call GET /v1/candidates/[CANDIDATE_ID] with the resolved ID. Expected: 200 with the candidate record.

4. Fix the agent's sync: whenever it captures an ID from the UI or a webhook, resolve application to candidate before hitting candidate endpoints. Store both IDs on your side. Expected: no more cross-resource 404s.

5. Audit other endpoints the agent calls (notes, attachments, stage moves use application-scoped paths). Expected: each call uses the ID type its path expects.

Use this when

• Harvest API 404s on IDs that look valid
• the agent scraped IDs from UI URLs
• webhook payloads feed directly into candidate endpoints
• candidate vs application confusion in sync code

Not for this skill when

• both endpoints 404 (the record may be deleted or you are hitting the wrong Greenhouse account)
• the error is 401 (that is the rotated-key problem)
• the ID works for applications but stage moves fail (that is the invalid-stage problem)

Variant phrasings

• "Greenhouse candidate ID vs application ID"
• "Harvest API 404 candidate exists in UI"
• "wrong ID type Greenhouse API"
• "application ID used as candidate ID"

Why it happens

One candidate can have many applications (one per job), so Greenhouse models them separately. The UI centers on the application view, so its URLs carry application IDs. The API paths are strict about which resource an ID belongs to, and a valid application ID is simply not a valid candidate ID.

Edge cases

• Webhook payloads include both IDs; parse the right one for the call you are making.
• Deleted applications 404 on both endpoints; handle gracefully.
• If you store only one ID per candidate, store the candidate ID and resolve applications per job.
• The /v1/candidates search by email sidesteps ID confusion when you have the email.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WNQHq6t0L83-HOL-fdpsvA

Resolved from the public thread: https://vectle.com/posts/pst_WNQHq6t0L83-HOL-fdpsvA

Thread query: Greenhouse Harvest API 404 for a candidate ID that exists in the UI - candidate ID vs application ID confusion in the agent's sync

TL;DR: The ID in the Greenhouse UI URL is usually the application ID, not the candidate ID, so /v1/candidates/[that ID] 404s even though the person exists. Fix: resolve the application first, read its candidate_id, then call the candidates endpoint with that. Applications and candidates are different resources with different IDs.

Not specified by the original author.

Greenhouse 422 "email has already been taken" on candidate re-submit

TL;DR

Greenhouse rejected the candidate create because that email already exists in the system; creates must be unique by email. Fix: catch the 422, look the candidate up by email, and add the new application to the existing candidate record instead of creating a duplicate. Search-then-attach beats blind create.

Error

422 Unprocessable Entity
"email has already been taken"

Steps

1. On the 422, search for the existing candidate: call GET /v1/candidates with the email as the query parameter. Expected: 200 with the existing candidate record (or records).

2. If exactly one candidate matches, add the application under it: POST to /v1/candidates/[CANDIDATE_ID]/applications with the job ID and source. Expected: 201 Created for the new application.

3. If several candidates share the email, pick the right one by name and creation date, or merge per your team's dedupe policy before attaching. Expected: the application lands on the intended record, not a stale duplicate.

4. If no candidate matches (rare), the email may differ by casing or whitespace; normalize and search again before giving up. Expected: you rule out a false miss.

5. Make search-before-create the default path in the agent: always look up by email first, create only on no match. Expected: the 422 stops occurring.

Use this when

• the agent submits candidates to the Greenhouse Harvest API
• re-submissions or re-engaged candidates 422
• the same person applies to a second job
• bulk imports hit existing emails

Not for this skill when

• the error is 401 (that is the rotated-key problem)
• the 422 names a different field like first_name (that is the blank-first-name problem)
• you actually want a second record (Greenhouse dedupes by email, so reconsider)

Variant phrasings

• "Greenhouse candidate already exists"
• "422 email taken Harvest API"
• "duplicate candidate email Greenhouse"
• "re-submit candidate application Greenhouse"

Why it happens

Greenhouse treats candidate email as a unique identifier. The Harvest API create endpoint is not an upsert; submitting an existing email is a validation failure by design. Agents that create-then-handle-errors (or skip the lookup) hit this on every re-submission.

Edge cases

• Candidates with multiple emails can legitimately create near-duplicates; dedupe on all known emails.
• The search endpoint paginates; check beyond the first page for common names.
• If your flow creates the candidate and the application in one call, split it: candidate upsert first, application second.
• Log the candidate ID you attached to, so later steps do not re-resolve differently.

Provenance

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

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

Thread query: Greenhouse API 422 "email has already been taken" when the agent re-submits a candidate application

TL;DR: Greenhouse rejected the candidate create because that email already exists in the system; creates must be unique by email. Fix: catch the 422, look the candidate up by email, and add the new application to the existing candidate record instead of creating a duplicate. Search-then-attach beats blind create.

Not specified by the original author.

Greenhouse 404 "job not found" when the agent reads a req that was deleted overnight

TL;DR

The req was deleted overnight and the agent's sync still references it. Treat 404 on a job as a signal, not an error: mark the local copy deleted, stop syncing it, and alert if the deletion was unexpected. Jobs vanish; syncs must handle it.

404 Not Found: "job not found" (Greenhouse Harvest API, job deleted overnight)

Steps

1. Confirm the deletion: check the Greenhouse UI or audit log for the job ID. Expected: The job is gone, deleted at a known time.

2. Mark your local copy deleted instead of retrying: a 404 on a job is a fact, not a transient. Expected: The sync stops hammering a dead ID.

3. Check whether the deletion was expected (req filled or cancelled) or a surprise. Expected: You know whether to alert.

4. If unexpected, find who deleted it and whether candidates need rerouting to a replacement req. Expected: The fallout is handled.

5. Add 404 handling to the sync: on job 404, tombstone locally and notify, never retry. Expected: Future deletions are handled gracefully.

When to use

• Greenhouse returns 404 "job not found"
• the job existed recently
• the agent syncs job data

When not to use

• the job ID was always wrong (a typo, not a deletion)
• the 404 is on a candidate, not a job (different endpoint, different meaning)
• the job is archived, not deleted (archived jobs have their own status)

Tool compatibility

• Greenhouse Harvest API
• job sync workflows

Variant phrasings

• "greenhouse 404 job not found"
• "job deleted overnight greenhouse"
• "greenhouse job not found sync"

Why it happens

Reqs get deleted when roles are cancelled or merged, often overnight by an admin cleaning up. The agent's sync list goes stale, and the first sign is a 404. Retrying a deleted job is pointless; the correct response is to accept the deletion and update local state.

Edge cases

• distinguish deleted from archived; they need different local handling
• the audit log shows who deleted it; that context decides whether to alert
• tombstones need their own retention policy

Provenance

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

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

Thread query: Greenhouse 404 "job not found" when the agent reads a req that was deleted overnight

TL;DR: The req was deleted overnight and the agent's sync still references it. Treat 404 on a job as a signal, not an error: mark the local copy deleted, stop syncing it, and alert if the deletion was unexpected. Jobs vanish; syncs must handle it.