Introduction
I have spent the last four years building ATS integrations. Kini offers 75 of them today. So it was a strange sentence to say on stage, at a job board conference in London this October: ATS integrations are dead.
They are not, of course. But one thing about them is ending, and I think it will end faster than most of the industry expects. For as long as job boards have offered Quick Apply, the rule has been the same: no ATS integration, no Quick Apply. A candidate gets a native application only if someone, somewhere, has built and configured a connection to that employer's applicant tracking system. Everyone else gets a redirect to a careers page and a form that many of them will abandon. That rule is about to break, and this article is about why it matters, what changes, and what could still get in the way.
TL;DR
- Quick Apply is how a job board proves its value. It turns traffic into measurable applications, shows which bought traffic actually converts, keeps candidates on the board and spares them typing the same data twice.
- The rule that blocks it: most job boards only offer Quick Apply where an ATS API integration exists. No integration, no Quick Apply, and every employer without one gets a redirect.
- The real cost is not the build. An integration means four jobs: building it, adapting it whenever the ATS changes its API, monitoring and fixing it, and onboarding every employer for credentials. The last one routinely becomes the bottleneck, and the reason most jobs are posted without Quick Apply.
- Every employer already has an interface into its ATS: its application form. It defines the questions, the required fields and where the application lands. Kini AI makes that form usable like an API, so most employers no longer need an integration project.
- It works at scale. In an analysis with one of Germany's largest job boards, 95% of the companies tested could be supported via Kini AI, and Kini measured a 99.5% initial success rate across a year-long beta with several job boards.
- Integrations become a choice, not the entry ticket. Strategic customers and two-way data still justify a direct integration. They should no longer decide which candidates get a native application.
Why does Quick Apply matter so much for job boards?
Because it changes what a job board sells: not clicks that disappear into someone else's form, but applications it can count.
It delivers measurable results. A redirect ends the board's view of the candidate at the click. A native application is a result the board can report: this many candidates, for this job, from this booking. That matters more every year, because the market is moving to paying for outcomes. Indeed now prices most Sponsored Jobs on pay per started application, and qualifying jobs are enrolled automatically, with no option to switch back to pay per click (Indeed, Oct 2026). A board that can count applications can offer models like that. A board that only sends traffic cannot.
It makes traffic buying smarter. A large part of the budget of a job booking already goes into buying traffic on other channels, much of it programmatically. Programmatic platforms decide "when to shift budget toward the sources producing actual applicants" and report cost per apply by channel (DirectEmployers, Aug 2026). That only works if the board can see which traffic converted into an application. With redirects, it is optimising on clicks and guessing the rest.
It stops paying twice for the same candidate. Every redirect sends a candidate the board has already paid to attract onto another website. Some of them apply. Many do not come back, and winning them back means buying the same attention again.
It is simply a better experience. No second form, no repeated data entry, everything in one interface, and far faster. Redirects cost real applications: in a 2025 iCIMS survey of 1,000 US hourly workers, 60% said they had started an application and never finished it, and the most cited reason, at 50%, was a form that was too long or time-consuming (iCIMS, Sep 2025). Faster applying means more candidates apply.
So native apply is not a feature any more. It is what candidates have come to expect, and the basis of how a job board can prove what it is worth.
Why has Quick Apply been held hostage by integrations?
Because the application always has to end up in the employer's ATS, and until recently the only reliable way to get it there was an integration built for that system and configured for that employer.
On paper, that is one integration. In practice, it is a matrix that grows in two directions at once. Every ATS models a job, an application and a screening question differently, authenticates differently, handles CVs and attachments differently, and changes its API on its own schedule. Every new customer can bring a new system. And every employer on a system you already support still has to be connected individually. The complexity does not add up, it multiplies: number of systems times number of employers, each connection a small product of its own that has to be kept alive.
Most boards never decide to take this on. It happens one customer at a time, until a team that set out to run a job board is maintaining connectors to dozens of systems. You have accidentally become an integration company.
What does the integration tax actually cost?
Far more than the build. Every integration carries four costs, and only the first one shows up in a roadmap.
| Cost | What it means in practice | Who pays it |
|---|---|---|
| Build | A connector per ATS, each with its own data model and authentication | The job board's engineering team |
| Adapt | Rework whenever the ATS changes or deprecates its API | Engineering, indefinitely |
| Monitor and fix | Watching every connection and repairing the failures that inevitably happen | Engineering and support |
| Onboard | Getting access and credentials from every single employer | Sales, customer success and the employer's administrators |
The fourth cost is the one that kills Quick Apply for most employers. Even when recruiters receive a simple guide for finding their API keys and sending them to the partner, in most cases it does not work. The recruiter is too busy, or hesitant to touch the ATS settings, or the request is forwarded to a technical team and gets lost there. Setting up a single integration therefore often means many stakeholders, and a lot of time and resources.
That is fine for a strategic customer on a multi-year contract. It is impossible for a one-off booking, for an employer whose HR team has no ATS administrator, or for a job that reached the board through an agency and comes with no direct relationship to the employer at all. Those employers are not edge cases. For many boards they are most of the customer base, and under the integration-first rule, none of their candidates get a native application.
What is changing right now?
The question we ask. For years, our own default answer to "how do we get this application into the ATS?" was the obvious one: integrate with the ATS API. Then we realised something very simple.
Every employer already has a way of getting applications into its ATS. It already defines the questions. It already defines the required fields. It already knows where the application needs to go. It calls this its application form.
So we asked ourselves: what if we treated the application form like an API? Not by replacing it. Not by asking the employer to change anything. But by using the application process that already exists. That idea became Kini AI, which moved from beta to general availability on 1 September 2026.
That shift in question is the whole point. "Do we have an integration with this employer's ATS?" has a different answer for every employer. "Does this employer have an application form?" has almost always the same answer: yes.
How does an application form become an API?
By turning the form's questions into fields the job board can show natively, and submitting the candidate's answers back through the same form.
Compare the two models. Today, to sync candidates directly into an ATS, a board builds the integration, keeps adapting it, monitors it, and onboards every employer. With the form as the interface, the flow looks like this:
- You already have the job URL. You send it to Kini.
- Kini returns the fields the employer's application form requires.
- The candidate applies directly on your job board.
- You send the candidate and their answers to Kini.
- Kini submits the application through the employer's existing application process, CV included, directly into the ATS.
No integration project for that employer. No API credentials. No technical onboarding. And the recruiter still receives the application exactly where they expect it: inside their own ATS, through the same door as every other application. The ATS stays the system of record, and nothing about the employer's setup changes.
Does it actually work?
The idea only matters if it holds up against real employers, so we tested it for about a year in beta with several job boards. Two results convinced us to launch.
The first is coverage. In an analysis together with one of the largest job boards in Germany, Kini AI could support 95% of the companies tested. The second is delivery quality. Across the beta, Kini measured a 99.5% initial success rate for submitted applications.
Both numbers are our own measurements, from our own beta. They are not an independent audit, and they do not guarantee the result for any single employer. Which is why my suggestion to a sceptical job board is the same one I made on stage: do not trust our numbers, test your own jobs. Bring us one job URL, preferably your worst one, the kind where you currently have no good way of offering Quick Apply, and see whether it turns into a native application flow.
with your stack?
What will the next months look like?
If the integration stops being the entry ticket, a few things follow quickly. These are expectations, not certainties, but they follow directly from the economics above.
Quick Apply moves from premium tier to default. Today many boards sell native apply as something reserved for integrated customers. When it no longer depends on an integration, holding it back becomes a choice to lose candidates, and boards that keep doing so will be competing against boards that do not.
"Which ATS do you support?" stops being the sales question. For years, integration lists have been how boards and vendors competed. When almost any employer with an application form can receive native applications, the question becomes whether candidates can apply natively on every job, not whether a specific connector exists.
Integrations move up-market, to where they earn their cost. A direct integration is still the right tool when a board needs more than a delivered application: status updates, hiring outcomes, data flowing in both directions. Indeed, for example, requires integrated ATS partners to give clients access to Disposition Sync, the route by which hiring results return to the channel (Indeed Partner Docs, Oct 2026). That is where integrations will concentrate: strategic relationships, high volume, two-way data.
The long tail finally gets the same candidate experience. The one-off booking, the agency-sourced job and the employer without an ATS administrator have always been last in line. They stop being second-class.
What could still get in the way?
Plenty, and it would be dishonest to pretend otherwise. These are the blockers I expect to matter most.
| Blocker | Why it matters | What softens it |
|---|---|---|
| Forms that require an account | If the employer's form makes candidates register before applying, the form route does not work yet | A candidate-friendly alternative we are working on; until then, a direct integration |
| Fraud and bot defences | Employers are hardening their funnels against fake and automated applications | Real candidates, applying on a real board, with consent captured |
| Forms change | A redesigned form can break a submission just as an API change can break an integration | Monitoring every route, not only integrations |
| No data coming back | A form delivers the application, but status and outcome do not travel back through it | A direct integration where the loop matters |
| Gatekeeping habits | Partner programmes, certification and "integrated tier" pricing were built around the old rule | Time, and boards that move first |
The fraud question deserves more than a table row. Gartner projects that by 2028, one in four candidate profiles worldwide will be fake, and 54% of recruiting leaders it surveyed agreed that AI has made candidate fraud a significantly larger problem (Greenhouse, Jun 2026). Employers will respond with more verification, not less. That is a genuine tension: the same automation that lets a legitimate board submit through a form could let bad actors flood it. The answer, in my view, is to be unmistakably the legitimate case: a real candidate, applying on a known job board, answering the employer's own questions, with the employer's privacy policy passed along as a question the candidate confirms. Anything less will, rightly, get blocked.
Are ATS integrations really dead, then?
No. If I said that, I would be in trouble with our entire tech team. We are still going to build integrations, and the reasons for running them as a managed service rather than as a pile of one-off projects still apply.
What I no longer believe is that they should determine which candidates get a native application experience and which do not. The 75 integrations we offer are the right answer for a strategic customer. They were never the right answer for the employer who books one job and has no one to send API credentials. The API integration should be a choice. Not the entry ticket.
I first made this argument in a keynote at Job Boards Connect 2026.
What to do next
Three things you can do this week:
- Ask your team why Quick Apply is not enabled for every customer. If the answer is "because it requires a proper ATS integration", challenge that assumption.
- Count the employers on redirect today, and sort them by reason. No integration for their ATS, no credentials, no direct relationship. Each is a different problem, and only some of them need an integration to solve.
- Pick your worst job URL. The one where you currently have no good way of offering Quick Apply. That is the best test of whether the rule still holds.
If you want to run that test with us, book a conversation with our team and bring the URL.
