Why nothing can press Send on your job application

Software cannot submit a job application to Greenhouse, Ashby, Lever, Workable or Rippling on your behalf. Not "should not" — cannot, unless it is willing to defeat a captcha or hold a credential that belongs to the employer. We went looking for a way to do it before we built anything, found the same wall in five places, and then designed the product around the wall.

The wall is two locks, not one

The first lock is the captcha. On every board we checked, the token that clears submission is issued for that board's own origin and verified against it. A server somewhere else cannot mint one. A headless browser can sit on the page and still fail the behavioural half of the check, which is what the check is for. This is not a gap somebody forgot to close — it is the specific thing these vendors sell to their customers.

The second lock is the API. Server-side endpoints for creating a candidate do exist, and they are wonderful, and they are not yours. They authenticate with a key issued to the company running the board. An applicant has no key and cannot be given one. So the documented path in and the undocumented path in are shut by two different mechanisms, and closing one would not open the other.

You can get around all of this by driving a real browser on the applicant's own machine with a stolen-looking session. Some tools do. It works until the vendor tightens something, and then it silently stops working, and the applicant finds out from the silence.

What we built instead

We stopped one step earlier, on purpose.

Crossing reads the employer's published question set, fills in every answer it can justify from your profile and your résumé, writes the receipt, and opens the employer's own application page in your browser with the answers in place. Then it stops. You read what is on the screen and you press Send.

There is no submit path in the code and there is not going to be one. What src/lib/apply/engine.ts returns is either a URL to hand you or a failure — there is no third case, so "submitted" is not a state this product can represent. The constraint is held by the compiler rather than by a comment asking people to be careful.

The part that sounds like a downside

It is a downside. One extra click, on somebody else's page, every time. We are not going to pretend that click is a feature of the user experience.

What we will say is that the alternative is worse than it looks. Employers are now filtering applications that arrive by cannon — that is why "we applied to 400 roles for you" services produce a mailbox full of nothing. The volume is visible from their side, and the name attached to it is yours, not the tool's. A product that fires 200 applications a week is spending your reputation on a strategy that stopped working.

So: apply to fewer jobs, with a résumé that has actually been pointed at the posting, and read the form before you send it. That is the whole opinion. The queue exists to make that fast, not to make it disappear.

What the click buys you

Because a human is on the employer's page at the end, three things stay true that would otherwise not:

• Nothing is submitted that you have not seen. There is no category of "application I did not know I sent".
• Demographic and EEO questions stay blank unless you fill them in. We never infer gender, race, veteran or disability status from a résumé, and we never remember those answers between applications.
• When a board changes its form, the failure is visible to you in the same second, instead of being a silent drop rate you discover six weeks later.

If you want the mechanics rather than the argument, the features page lists every capability with what it actually does, and the help centre has the short version of this post at why we don't press Send.