What an Ashby application asks you for

The short answer

Ashby-hosted job boards load their entire application form from a public endpoint you can query without ever logging in or opening the page. It works differently than Greenhouse's approach, a GraphQL call instead of a simple web address, but the result is the same: the fields, their types, and what is required are knowable before you commit to anything.

A GraphQL endpoint, not a web address

Where Greenhouse hands back its form definition from a plain URL, Ashby's version lives behind a single GraphQL operation: POST https://jobs.ashbyhq.com/api/non-user-graphql?op=ApiJobPosting. No account, no session, no authentication header. Send the right query with the right job identifiers and the response comes back with the posting's full form.

There is a catch that makes this harder to work with than it sounds. GraphQL APIs usually support introspection, a built-in way to ask the API to describe its own available fields and types. Ashby has introspection turned off on this endpoint. That single setting is the difference between requesting a schema outright and having to find one by testing, field by field, what the endpoint accepts and what it sends back. The endpoint is public. Its shape is not handed to you. It has to be found.

What the response looks like once you have it

Trimmed to the relevant part, a job posting's form comes back with a list of application questions and their properties, something close to this shape:

{
  "applicationFormDefinition": {
    "sections": [
      {
        "fields": [
          { "title": "Full Name", "type": "text", "isRequired": true },
          { "title": "Resume/CV", "type": "file", "isRequired": true },
          { "title": "LinkedIn URL", "type": "text", "isRequired": false },
          { "title": "Are you legally authorized to work in the country where this role is based?", "type": "yes_no", "isRequired": true }
        ]
      }
    ]
  }
}

Same idea as any other application form, grouped into sections, each field carrying a type and a required flag. The naming conventions differ from Greenhouse's, isRequired instead of required, fields nested under sections instead of sitting in a flat list, but the information an applicant actually needs is the same information, just shaped differently underneath.

Why the probing approach matters

Introspection being disabled is a deliberate choice, not an oversight, and it changes how anyone working with this endpoint has to operate. A normal GraphQL API lets you ask it directly what it supports before you ever query real data. This one does not, so confirming that a field like isRequired behaves consistently across different job postings, different employers, and different field types takes deliberate testing rather than a single trusting request. That extra step does not change what ends up in front of you as an applicant. The page still renders the same form either way. It changes how much confidence anything reading the form ahead of time can have that it has actually found every field, rather than just the ones it happened to test for.

What actually shows up on the page

None of the mechanics above are visible when you are the one filling out the form. You see a name field, an email field, a resume upload, the six pieces of information nearly every board asks for, followed by a run of screener questions covering work authorization, location, and the rest of the usual list. An Ashby-hosted form does not look meaningfully different from a Greenhouse one to the person filling it in. The GraphQL endpoint underneath is a convenience for anything reading the form in advance, not a change in what is actually being asked of you.

That distinction is worth holding onto whenever a post like this one gets into endpoints and query shapes. The engineering detail explains how a form can be known before you load it. It says nothing about the form itself being harder or easier, longer or shorter, than any other board you might land on that same afternoon. Two postings can share an identical set of fields and questions while one happens to be readable in advance and the other is not, and neither fact tells you anything about the company, the role, or how competitive the process will be.

What this means if you are the one applying

Practically, an Ashby-hosted posting behaves like the Greenhouse ones covered in Greenhouse shows you the form before you apply: the six universal fields show up, name, email, phone, resume, LinkedIn among them, a set of screener questions follows, and whatever is marked required is genuinely required, not a guess. The difference is invisible to you as an applicant. You never see the GraphQL call. You see a form that renders the same way any other form does. The public endpoint matters mainly to anything, or anyone, trying to know the form before the page loads, not to how the page looks once it does.

For the fuller pattern behind what any of these forms tend to ask regardless of which system is running them, six fields that never miss and a recurring set of screener questions, see what ATS application forms actually ask for.

Where Ashby fits next to the other two

Ashby is one of three systems behind nearly every employer board we track, alongside Greenhouse and Lever. All three ask applicants for a similar core set of information. Where they genuinely differ is in how much of that form is knowable in advance, how the page itself is laid out, and how autofill and resume parsing behave once you start typing. We put the three side by side, as an applicant rather than as an engineer reading endpoints, in Lever, Greenhouse and Ashby, compared as an applicant.

None of this changes what you are actually being asked. A field labeled "Resume/CV" and required on an Ashby board is doing the same job as a field labeled "Resume" and required on a Greenhouse board. The endpoint underneath is a convenience for anything reading the form ahead of time, not a difference in what the employer needs from you.

iapplyai.app queries this same endpoint before you ever open the posting, so an Ashby-hosted job gets scored against your resume and its screener questions get drafted before the page has loaded in your browser.