DEV Community

Cover image for An HTTP 200 is not a delivered job application
Ava Bagherzadeh
Ava Bagherzadeh

Posted on

An HTTP 200 is not a delivered job application

AI Applyd is live on Peerlist Launchpad, week 38

We are launching on Peerlist this week. If this is your kind of problem, come and tell us where it still falls short: AI Applyd on Peerlist Launchpad

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.

An application that only reads as sent once the employer confirmed it

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.

We apply where the jobs really live, across twelve hiring systems

  • 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
Enter fullscreen mode Exit fullscreen mode

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?


Come and kick the tyres on the launch page, it is live all week and every comment there reaches me: peerlist.io/firstexhotic/project/ai-applyd-mcp

Top comments (0)