What actually happens to your application after you press Submit

Your application becomes a row in the employer's applicant tracking system, attached to that one posting, with your answers stored as values against fields a recruiter configured before the job went live. Most of what happens to it next was decided by that configuration — not by anything you do afterwards.

The useful part is that a lot of the configuration is published. We read it, because Crossing pre-fills these forms, and reading it turns out to answer the question better than any "your application journey" diagram does.

Everything below is our own measurement, taken across live postings on 2 August 2026. Where we do not know something, we say so rather than fill it in.

The job ad and the application form are two different objects

This is the finding that reframes everything else.

Greenhouse serves both from the same endpoint, and by default it serves only the first:

GET https://boards-api.greenhouse.io/v1/boards/{board}/jobs/{id}
GET https://boards-api.greenhouse.io/v1/boards/{board}/jobs/{id}?questions=true

Without ?questions=true the response is 200, it looks complete, and questions, compliance, demographic_questions and location_questions are simply absent. On stripe/7440963 the parameterless call returns 19 keys and not one of them is a question.

So every tool that scraped the job ad has seen the description, the title and the location, and has never seen the form. That is most of the internet's job data. It is why an aggregator can show you a posting that closed weeks ago, and why "one-click apply" on an aggregator can only ever mean emailing your résumé somewhere.

What each board publishes about the recruiter's setup

Greenhouse publishes the question set, the required flags, and the option lists, plus two mutually exclusive shapes for the US self-identification block — compliance on some boards, demographic_questions on others, neither on plenty. Stripe, Coinbase, Databricks and Dropbox use the first; Asana uses the second; Mozilla uses neither. Of the 36 live payloads carrying compliance, every single one had the same structure: a preamble block with no questions in it — the Paperwork Reduction Act statement — followed by four questions.

It also publishes data_compliance, which is how you know before you start that the form will not submit until you tick a data-retention consent, and an optional ai_disclaimer that some employers now attach.

Ashby does not expose the form over REST at all. The public posting API stops at the job ad; the form comes from the same unauthenticated GraphQL call the board's own page makes, and the only header that matters is content-type. What is interesting is the response: applicationForm.id is minted fresh on every call. Three identical requests to the same Cohere posting returned three different ids. It is a single-use token for one read, not an identifier of the form — which tells you the submission is bound to a form instance issued when your page loaded, and that a stale tab is not the same thing as a live one.

Lever hides the entire recruiter configuration inside the page you are looking at. Every question card renders a hidden input named cards[<uuid>][baseTemplate] whose value is the entity-escaped JSON of the template the recruiter built — field types, required flags, option lists, help text. If you want to see how the person hiring you set up their form, open a Lever apply page, view source, and search for baseTemplate. That is not a leak; it is how their front end works. It is also the only way to get at it, because Lever's public postings API says outright that it does not expose custom questions, and on a Lever board the custom questions are most of the form.

Two things we found there that the obvious implementation gets wrong. The field naming is flat — cards[<uuid>][field0], zero-based, no fields or value segment — and not the cards[uuid][fields][0][value] shape repeated in every write-up we could find. And the résumé input carries no required attribute even when the label is starred, on all three boards we sampled. Required-ness on Lever lives in a <span class="required"> in the label, which means a tool reading the attribute concludes your résumé is optional.

Workable publishes the whole form as JSON against the posting shortcode alone — no account slug, no key. It includes the employer's real file limits per upload field: accepted types, accepted MIME types, maximum size. It also pre-fills the address box from the geography of whoever made the request, which in our case is a datacentre. We drop that value rather than carry it through, and we tell you their page will do it too.

Rippling attaches the application to the posting object, in two parts: a fixed contact block, and the recruiter's own question groups. additionalQuestions is a list of groups rather than one group — the posting we sampled had two, and a reader that takes the first silently loses the second employer's questions. Some questions arrive typed KNOCKOUT. That is the board telling you, in its own payload, that one answer can end the application without a person reading it.

Personio loads its form after the page renders, so almost nothing is visible. What is in the HTML is a map called application_form_fields_v2 naming each field and whether it is required — no labels, no options. The employer's own custom questions appear as custom_1 with no wording attached. We show them as "this employer's own question 1" and say plainly that you will read it for the first time on their page, because inventing a plausible label would be worse than admitting the gap.

The parts we cannot see, and will not invent

We do not know how any of these vendors rank, score or route an application after it arrives. We do not know whether a human opened yours. We cannot see the recruiter's rejection reasons, the review queue order, or whether a résumé-matching score is switched on for that requisition.

Nobody outside the company can. Articles that draw a confident flowchart of "what happens inside the ATS" are drawing the vendor's sales diagram, which describes what the product can be configured to do and not what this employer configured it to do.

What we can tell you is which decisions are already made at the moment you press Submit.

The three things decided before you click

1. Knockout answers. On Rippling these are typed in the payload. On every other vendor the same effect is achieved with a required select and a filter. If a question has a wrong answer, it has that answer whether or not you read the question carefully.

2. Which fields the recruiter made mandatory. This varies enormously and it is entirely the employer's choice. On Lever, one board asks for nothing beyond a name and an email, and the next insists on phone, current company and LinkedIn before it will submit. There is no standard, so "the ATS requires it" is almost always wrong — a person chose it.

3. Whether your file parsed at all. A PDF with no text layer uploads perfectly and arrives empty. See what an ATS actually parses out of your résumé file.

Two things worth doing with this

Apply on the ATS board, not on the aggregator copy. The board row is the live object. It is also frequently not where you expect: 1,147 of the Greenhouse postings in our index apply on an employer's own domain — stripe.com/jobs/search?gh_jid=…, careers.airbnb.com/positions/… — which is still Greenhouse underneath. A posting that has vanished from the board is closed, whatever the aggregator still shows.

Read the form before you fill it. The questions that can end your application are on the same page as the ones that cannot, and they look identical. This is the entire reason Crossing shows you the employer's real questions, filled in, on one screen — and then makes you press Send on their page yourself. Where the product stops, and why.