Greenhouse shows you the form before you apply

Yes, and here is exactly where

Greenhouse publishes the full definition of its application form in the open, before you ever load the page. Every field the employer asks for, what type of answer it expects, and whether it is required or optional, all sitting at a public web address you can request directly: GET https://boards-api.greenhouse.io/v1/boards/{slug}/jobs/{id}?questions=true. No login, no application started, no commitment. You are reading the form, not filling it out.

That is unusual. Most of the web does not tell you what a form is going to ask until it renders in your browser. Greenhouse does, because the same data that draws the page for a human is also available as a plain response for anyone who asks for it.

What is actually in that response

Swap in a real board's name and a real job's ID and the response comes back as structured data rather than rendered HTML. Trimmed down, the shape looks roughly like this:

{
  "questions": [
    { "label": "First Name", "type": "input_text", "required": true },
    { "label": "Resume", "type": "attachment", "required": true },
    { "label": "Cover Letter", "type": "attachment", "required": false },
    { "label": "LinkedIn Profile", "type": "input_text", "required": false },
    { "label": "Are you authorized to work in this country?", "type": "boolean", "required": true }
  ]
}

Every question the applicant will eventually see is in there: its label, its type, such as short text, attachment, dropdown, or boolean, and a required flag that tells you outright whether leaving it blank will stop your submission. Nothing in that list is inferred or guessed. It is the same definition Greenhouse's own page reads to build the form you would otherwise have to open first.

What reading these at scale actually showed

We used exactly this endpoint to read the real form behind 20 live openings across 7 companies. The required flag is where it paid off most on the cover letter question specifically. Across the sample, a cover letter attachment was marked optional on 19 of the 20 jobs and was not present as a field at all on the remaining one. It was never marked required. Once you can read that flag before applying, you stop guessing whether a form is going to gate you on a cover letter, and you start knowing.

The same logic extends to every other field. Whether a phone number is required, whether the form wants a portfolio link, whether an EEO section is present at all, it is all sitting in that same response. For the fuller breakdown of what required actually commits you to versus what you can leave blank without consequence, see which application fields you can safely skip.

What you need before you can read it

The endpoint takes two identifiers: a board slug, the short name in the employer's own careers URL, and a job ID, a number tied to that specific posting. Both are visible in the ordinary careers page you would have opened anyway, sitting in the address bar and in the page itself, so nothing about this involves extracting hidden information. Get either one wrong and the endpoint simply returns nothing useful, which is a reasonable safeguard. This only works once you already have a real, specific posting in front of you. It is not a way to go looking for jobs that have not been published, only a way to see more of one you already found.

Why this matters more than it sounds like it should

Knowing the form in advance changes the order you do things in. Instead of opening a tab, starting an application, and discovering three questions in that a cover letter is expected, you know before you start whether this one wants it, whether it is going to ask about sponsorship, and how many fields stand between you and submit. For a single application that saves a few minutes. Across a real job search it is the difference between deciding what to write once, calmly, and writing it under the pressure of a half-finished form.

Picture two versions of the same evening. In one, you find a promising role at nine at night, open the application, and twenty minutes in discover it wants a cover letter you have not written, so you either rush one out half-focused or abandon the application until tomorrow. In the other, you already know before you click apply that this posting skips the cover letter field entirely, so you spend those twenty minutes finishing the application instead of stalling on a field that was never going to block you. Nothing about the job changed between those two versions. Only what you knew going in did.

It is also why tools that automate part of an application can work reliably against Greenhouse boards specifically. When the form itself is published as data, a tool does not have to guess at field names or scrape a rendered page that might change its layout tomorrow. It reads the same definition the page reads, so what it fills in matches what the employer actually asked for, not an approximation of it.

Not every system works this way

Greenhouse is one of three systems behind almost every board in the graph we track, and it is not the only one that exposes its form ahead of time. Ashby does something similar through a different mechanism entirely, a public GraphQL endpoint rather than a plain response, which we cover in what an Ashby application asks you for. The shape of what gets exposed differs between the two. The fact that either exposes anything at all is the exception, not the rule, across the web generally, and it is worth treating as a small advantage while you have it rather than assuming every employer's board works this way.

For the full picture of what forms ask regardless of which system is running them, six universal fields and a recurring set of screener questions, start with what ATS application forms actually ask for.

iapplyai.app reads this exact endpoint before it ever asks you to look at a job, so the fields, the required flags, and the screener questions are already known and matched against your resume by the time you see the posting.