Your AI workflow can read an open job but cannot find the candidate's interview history. The first diagnosis should be the API boundary. A public careers feed and an internal recruiting integration solve different problems. Giving the careers component a more powerful credential can expose private information without fixing a bad data model. Start by deciding what the workflow needs to read and what it is allowed to change.
Choose by the task, not by the API name
Greenhouse describes its Job Board API as a way to retrieve published job information and build custom careers pages and application forms. Harvest serves internal candidate and job integrations. It includes authenticated reads and supported operations that change recruiting data. An AI assistant may need both, but the components should have separate responsibilities.
| Task | Starting point | Boundary to check |
|---|---|---|
| Display published vacancies | Job Board API | Public job posts for the intended board |
| Build a custom application form | Job Board API | Job-specific questions and authenticated submission |
| Read internal recruiting records | Harvest | Current endpoint support and authorized access |
| Change internal recruiting data | Harvest | Supported operation, permissions and review policy |
| Combine public jobs with private candidate evidence | Separate retrieval components | Controlled joining inside your application |
This is an integration design guide, not a claim that either API provides a ready-made AI agent. The evidence selection, review screen and operational controls described below are application responsibilities.
Keep public job research separate from private records
Job Board GET endpoints do not require authentication. That makes them useful for a careers page or a job research component that has no reason to access candidate records. Give that component a board identity and the fields needed for its task. Do not pass candidate credentials into it just because another part of the product uses them.
For a recruiter-facing assistant, define a separate internal retrieval step. Determine which Harvest resources the workflow needs and whether the current API supports those reads. Keep retrieved candidate evidence out of public search requests and public URLs. A job description can be public while the explanation of why a particular candidate matches it remains private.
Preserve the difference between a job and a job post
The Job Board jobs response distinguishes id, the job post identifier, from internal_job_id, the identifier for the job itself. Prospect posts can have a null internal_job_id. Treating those values as interchangeable creates incorrect links and failed handoffs. The application submission endpoint expects a job post ID.
Store the board token, post ID and internal job ID as separate fields in your own mapping. Include the source of each identifier. If the internal ID is absent, send the record to an exception path instead of inventing a value. Do not join systems on job title alone. Two posts can have similar titles while representing different hiring contexts.
Fetch the detail needed for the actual task
The jobs listing can include the full post description, departments and offices when content is requested. Custom job fields selected for exposure through the Job Board API appear as metadata. Do not assume that every internal field is public or that an absent field is empty in the recruiting system.
For a job summary, retain the original wording beside the generated draft. Ask the reviewer to check requirements, location and application destination. If the feed changes, mark an older draft for review rather than presenting it as the current posting. This freshness policy belongs in your integration and should be tested against edited and removed posts.
Build application forms from the current job questions
Application forms are job-specific. The Job Board documentation exposes questions and field definitions through the job detail response. A form copied from one vacancy can miss a required question on another. Retrieve the relevant definitions and map the applicant's answers to those fields deliberately.
Greenhouse states that its submission endpoint does not confirm required-field inclusion and will not reject applications merely for missing required fields. Validate required answers before sending. Put useful feedback on the form, and repeat the checks in your server handling so a skipped browser check cannot create an incomplete submission.
Keep the Job Board API key on the server. The documentation explicitly warns against exposing it through direct browser submissions. A public job listing does not make the application submission credential public. AI can help explain a question or prepare a draft, but it should not fabricate an applicant's answer to make validation pass.
Use current Harvest documentation for internal work
Greenhouse directs new integrations to Harvest v3 and is retiring v1 and v2 access according to applicable organizational cutoff dates. An older code sample may describe the wrong version for a new implementation. Confirm the organization's current setup before choosing authentication and endpoint details.
Inventory existing reads and writes separately. For each operation, record its purpose, current endpoint, required access and expected result. Verify supported operations in the current reference. Do not infer that a write exists just because a similarly named read does. This article does not assume that legacy permissions or request shapes carry over unchanged.
Test the complete recruiting handoff
- Choose a published job and verify its board, post ID and intended destination.
- Fetch its description and application questions without private candidate access.
- Run incomplete answers through the form and confirm that your application blocks submission.
- Test authorized internal reads separately from public job retrieval.
- Present any proposed internal update with the exact record and evidence for recruiter review.
- Read the resulting record or submission state through an appropriate authorized path and reconcile uncertain outcomes before retrying.
Use test records and an agreed test environment where available. Do not send fake applications into a live hiring process as a casual health check. Record what was actually tested, including which operations were read-only and which created data. Our guide to connecting a recruiting tool stack covers the wider handoff between systems.
Common mistakes to avoid
- Expecting a public jobs feed to expose candidate history.
- Using the internal job ID where the endpoint expects a post ID.
- Embedding a submission key in front-end code.
- Assuming an accepted application contained every required answer.
- Copying a legacy Harvest example into a new integration without a version check.
- Letting a generated summary change the source requirements or applicant answers.
How Remqa helps with Greenhouse AI integrations
Remqa builds AI agents for recruiting teams, including public job retrieval, private record handoffs and reviewed actions. The implementation starts with a narrow task and an explicit data boundary. If the work also involves a system move, the ATS migration scope should cover identifier mapping and the integrations that depend on it. Walk an engineer through one workflow and the records it touches before deciding what to automate.