Most explanations of a job application API stay theoretical. They describe the concept, wave at "automation," and move on. That's not particularly useful if you're trying to decide whether to build one, buy one, or trust one with real candidate data. So instead of staying abstract, this is a walkthrough of an actual job application API in production, The Boring Project, using its real request format, its real coverage numbers, and its real failure modes, because the honest details are what actually tell you whether something works.

What a job application API is supposed to do

The Boring Project's own definition sticks to exactly that scope: a developer submits a job URL and structured candidate data, the API completes the ATS form, and it returns a confirmation. No more, no less. That narrow, specific framing is worth noticing, because a lot of products in this space blur the line between "applies to jobs" and "helps you search for jobs," and those are genuinely different problems.

What the request actually looks like

Here's the entire integration surface, in one call:

POST https://apply-api.boringproject.ai/api/v1/sessions/apply

{

  "candidateProfileId": "prof_xyz789",

  "jobs": [

    {

      "companyName": "Acme Corp",

      "title": "Senior Software Engineer",

      "jobId": "12345",

      "link": "https://boards.greenhouse.io/acme/jobs/12345"

    }

  ]

}

You send a candidate profile reference and a job link. On the other end, the system resolves which ATS is behind that URL, loads the matching form adapter, fills every field, uploads the resume, answers the screening questions it can answer honestly, and files the application. Every request resolves to one of three outcomes through a webhook: submitted, needs_input, or failed, each with a screenshot receipt of the confirmation page. That's not a marketing description, that's the literal response contract, and having a defined "we genuinely don't know" state (needs_input) rather than forcing every request into success or failure is a small detail that says a lot about how the system is actually built.

Why the ATS is the whole problem

Anyone who's applied to more than a handful of jobs already knows this: no two application forms behave the same way. A job application API's real job isn't filling in text boxes, it's correctly identifying which applicant tracking system is rendering that particular form and adapting to it. The Boring Project currently covers more than 40 ATS platforms, including Workday, Greenhouse, Lever, iCIMS, Taleo, SuccessFactors, SmartRecruiters, Ashby, and Workable, all behind one consistent schema so the integration doesn't change depending on which employer's form you're hitting.

That coverage number matters less than what happens when it's wrong. The site includes a live coverage checker so a developer can type in an ATS name and see, plainly, whether it's supported yet, and states that an unsupported system becomes their backlog rather than the integrator's problem. That's a small design choice, but it's the kind of thing that separates infrastructure meant to be depended on from a demo built to look good once.

The part most products don't admit to

This is where a lot of "job application API" marketing gets vague, and where The Boring Project's own documentation gets unusually specific instead.

Workday is called out by name as the hardest case: multi-step, tenant-specific, sometimes requiring account creation before an application can even begin. Rather than smoothing that over, the site states plainly that the Workday adapter is the single largest file in their codebase and that median submission time is longer for it, and that they publish that number instead of hiding it. That's a trust signal worth paying attention to. A company that quietly claims "we support everything, instantly" is telling you less than one that tells you exactly where the friction is.

Screening questions get the same treatment. A question like "are you willing to relocate" isn't a form field, it's a decision with consequences for a real person. The stated approach is to answer only what can be answered truthfully from the candidate's own profile data, and to return needs_input rather than guess when it can't. That's stated directly as a policy, not an aspiration: fabricated answers get candidates rejected and get the API banned by the ATS, so it does neither.

Form drift is the third honest admission. ATS vendors change their interfaces constantly, often without warning. The stated response is synthetic test applications run daily against every adapter, with a failed test paging the team before a real integration ever sees the break, and breakage windows published on a status page rather than discovered by a developer through failed error logs. Whether or not you ever hit that scenario yourself, the fact that it's acknowledged upfront, with a specific process attached, is a meaningfully different posture than most competing tools take.

Three products, not one, because the problem isn't one-size-fits-all

Something else worth noting from an expertise standpoint: The Boring Project doesn't sell a single generic "job application API" and call it done. It splits into three products depending on what a team actually has.

The Apply API is the core primitive: a job URL and a candidate object in, a submitted application out, built for teams that already know where they want to apply and just need the filing handled. Search + Apply bundles job discovery with the same submission pipeline, for teams that have candidates but no job feed of their own. Managed Applies drops the integration requirement entirely: send a spreadsheet, get confirmations back, priced per application, for teams with volume but no engineering bandwidth to spare.

That kind of segmentation usually only shows up once a company has actually watched real customers hit real limits with a one-size-fits-all approach. It's a small but genuine signal of operational experience, not just a product built in theory.

Consent and rate limits, not just automation

A job application API that fires off applications with no constraints is a liability to everyone involved, the candidate, the employer, and eventually the API provider itself. The Boring Project's terms require candidate consent on every application and enforce per-employer pacing, stated explicitly as protecting both sides: employers don't want a flood of automated submissions, and candidates don't benefit from one either. That's the kind of operational detail that rarely makes it into a sales pitch, because it sounds like a limitation rather than a feature. It's actually the opposite. Rate limiting and consent requirements are what keep an ATS from blacklisting the API entirely, which is the thing that would actually break the product for every user on it.

What this means if you're evaluating one

If you're deciding whether to trust a job application API with real candidate data, the questions worth asking aren't "does it work" in the abstract. They're specific. How many ATS platforms does it actually cover, and is there a way to check before you commit to it. What comes back when an application is filed, a status code or an actual receipt. What happens when a screening question can't be answered honestly, does it guess or does it stop. And does the provider talk about where things break, or only about where things work.

The Boring Project's own answers to those questions are public: 40-plus ATSs with a live checker, a webhook plus screenshot receipt on every submission, an explicit needs_input state instead of guessing, and a full section of its own documentation dedicated to what's genuinely hard about the job. That level of specificity is a reasonable bar to hold any job application API to, including this one.

The actual point of any of this

Filling out the same application ten different ways is not a skill worth a person's time. A job application API exists to remove exactly that step, the paperwork, not the judgment. The products worth using are the ones that treat the hard parts, Workday's structure, screening question honesty, form drift, as the actual engineering problem, and say so plainly, rather than the ones that promise it's all effortless and hope nobody asks what happens when it isn't.