General
An HTTP 200 is not a delivered job application
Ava Bagherzadeh DEV Community 周榜
1 views
Every auto-apply tool I have taken apart marks an application "sent" at the same moment: the instant it dispatches the click. That is a read-back of our own input, and it is the weakest signal in the whole pipeline.
The four signals that look like proof and are not
I shipped all four of these at some point and had to take them back out.
1. Our own click. The submit button was pressed. Nothing about that tells you a request left the browser, or that the server accepted it, or that a row was written on the other side.
2. HTTP 200. A 200 means a server answered. Applicant tracking systems return 200 for validation errors, for a re-rendered form with a red field, and for a page that says "we could not process your application". A status code is not a receipt.
3. Our own database row. We wrote status = submitted. We wrote it. Scoring on a value you set yourself is circular, and it is the single easiest way to build a dashboard that is confidently wrong.
4. A page that looks like a thank-you. Heuristics on the confirmation screen are the most seductive of the four, because they are usually right. Usually is the problem. A cached page, a redirect to a generic careers landing page, or an ATS that renders the same shell for success and failure all pass a text match.
What we count instead
One thing: the employer's own system says the application arrived, and we can link to that evidence. A confirmation email from their ATS tied to that application. A post-submit screen we retained and verified as an employer confirmation. Nothing else moves a row to sent.
When we cannot get that, the application does not silently become a success. It says so, in plain words, and it names what it is waiting on.
What that bought
Refusing the weak signals forced the agent to get further on its own, because every shortcut we removed was a shortcut around a real wall.
It opens the employer's real hiring form on Greenhouse, Lever, Ashby, Workday, iCIMS, Personio, Teamtailor, SmartRecruiters, Recruitee, Breezy, Workable and Rippling.
It rewrites the resume for that specific posting and writes the cover letter in the candidate's voice.
It gets through account walls by itself: it signs up, verifies the email and resets a password using a private inbox we create for the user. The user is never asked for a code or a login.
It solves the captcha inside the vendor's own frame rather than giving up when the challenge sits in an iframe.
It stops pressing once the employer says yes.
If you want to poke at it
There is a remote MCP server, so the same tools run inside Claude, Cursor or ChatGPT. Streamable HTTP on Cloudflare Workers with OAuth 2.1 and dynamic client registration, so there is nothing to install and no API key to paste.
https://mcp.aiapplyd.com/mcp
The product itself is at aiapplyd.com.
I build AI Applyd - https://aiapplyd.com?ref=devto - auto-apply that proves your application arrived.
The question I keep asking, and the one that keeps changing this codebase: what would make you trust that an application actually landed?
Read original: https://dev.to/whateverneveranywhere/an-http-200-is-not-a-delivered-job-application-nlc
← Previous
Talk to your PWA and have it talk back — Speech Recognition & Synthesis (FieldKit companion)
Next →
MindSpark: Create and store private mind maps directly in your own git repo
Related
Talk to your PWA and have it talk back — Speech Recognition & Synthesis (FieldKit companion)
General
3
DEV Community 周榜
The State Snapshot: Your First Week on a New Project
General
3
DEV Community 周榜
Here’s How I Get the Most Out of My CLAUDE.md
General
1
DEV Community 周榜
How to Pay for a DeepSeek API Key When Your Country Blocks the Payment Rails
General
0
DEV Community 周榜
Comments0
No comments yet — be the first