The short answer
Greenhouse documents public GET endpoints for job-board data. Its official application POST endpoint requires a Job Board API key. Public access to a listing is not permission or credentials to use the official write endpoint.
Read a board's published jobs
The official Job Board API exposes a board's published job posts. Its documented content parameter can include descriptions. Replace the board token below with the token for the board you intend to query; the example token is a placeholder, not an active test board.
curl --fail-with-body \
'https://boards-api.greenhouse.io/v1/boards/YOUR_BOARD_TOKEN/jobs?content=true'Use the job-post ID for the job post
Greenhouse distinguishes a job-post id from an internal_job_id in the response. Its documentation identifies the post id as the target for an application. Preserve that distinction when normalizing records, particularly when one underlying job has several public posts.
Store the original board token, public post ID, URL, retrieval time, and your own internal record ID separately. A listing ID from another provider is not interchangeable with any of these identifiers.
The official submission endpoint has a different boundary
The official application endpoint requires Basic Auth using a Job Board API key. A developer building an employer's own career site can use the employer-authorized integration. A candidate-facing service should not assume it can obtain the same key for every employer.
Do not put an employer API key in client-side JavaScript or ask applicants to supply employer credentials. Use the official documentation for the exact authentication and submission contract if you are authorized to operate that integration.
Candidate-facing products need an explicit submission provider
A platform applying on behalf of candidates needs a supported candidate submission workflow, separate from reading public jobs. With Apply Guy, use a supported employer URL or catalog job ID, a candidate profile, selected documents, preflight checks, and the returned application resource.
The live form can include custom questions and verification requirements. Handle those through the supported API flow instead of assuming every Greenhouse job has an identical form. Current support and readiness belong in the API response, not in a hardcoded promise on your product page.
Sources and further reading
Provider and employer requirements can change. Follow the instructions for the particular application or integration.