Industry Insights

Programmatic Job Advertising With ATS Integration: Four Integration Levels Compared

· 5 min read

Yes, several platforms combine programmatic job advertising with ATS integration, but "integration" covers four very different depths. At the shallowest level the platform only reads your job feed. At the deepest level candidates are written into your applicant tracking system with their screening answers, and hiring outcomes flow back so the campaign can learn from them. The depth decides what the platform can see, what it can optimize toward, and what it can reasonably charge you for. This guide compares the four levels so you can tell which one a vendor actually offers before you sign.

What does "ATS integration" mean for a programmatic platform?

A programmatic job advertising platform buys and optimizes job ads across channels automatically. To do that it needs two things from your ATS: the list of open jobs, and some way to learn what happened after a candidate clicked. Every integration is a combination of those two data flows, jobs going out and candidates or outcomes coming back.

The data involved is well defined. The HR Open Standards Consortium publishes recruiting specifications in both XML and JSON, including a PositionOpening structure that "contains details about a position opening, including requirements for the position as well as administrative information, such as how to apply," and a Candidate structure for applicant data. Most vendor integrations are some version of moving those two objects between systems.

The practical difference between vendors is how many of those flows they support, and in which direction.

What are the four levels of integration?

Level 1: job feed in. The platform reads your open jobs from an XML or JSON feed exported by your ATS or career site. Candidates click an ad and apply on your ATS's own application page. The platform sees the click and nothing after it.

Level 2: tracked apply. The feed is the same, but a tracking tag or postback on your ATS confirmation page tells the platform when an application was completed. The platform now knows which clicks became applications, so it can report cost per application.

Level 3: application write-back. The platform hosts the application flow itself, usually a short mobile form with screening questions, and then posts the finished application into the right job in your ATS through the ATS's API. Major ATS vendors document this route publicly. The Greenhouse Job Board API lists open job posts with a GET call and accepts applications with a POST call to a specific job, authenticated with an API key. The Lever Postings API likewise lets an integration "programmatically apply to a job posting," with an API key that a Super Admin generates in the account's integration settings.

Level 4: outcome loop. On top of write-back, the platform reads status changes from your ATS, such as "interview scheduled" or "hired," and uses them to steer spend. It can also pass those outcomes on to the ad channels. Meta describes its Conversions API as a connection between an advertiser's data, including offline conversions from a CRM, and "Meta systems that optimize ad targeting, decrease cost per result and measure outcomes." Google Ads offline conversion imports serve the same purpose for Google campaigns: they "measure what happens in the offline world after your ad results in a click," provided you save the click IDs alongside the lead information you collect.

How do the four levels compare?


Level 1: feed in

Level 2: tracked apply

Level 3: write-back

Level 4: outcome loop

Jobs flow out of the ATS

Yes

Yes

Yes

Yes

Candidates flow into the ATS

Candidate applies on ATS page

Candidate applies on ATS page

Platform posts candidate via API

Platform posts candidate via API

What the platform can see

Clicks

Clicks and completed applications

Clicks, applications, screening answers

All of that plus interview and hire status

What it can optimize toward

Cheapest clicks

Cheapest applications

Applicants who pass screening

Applicants who get interviewed or hired

Billing units it can support

Cost per click

Cost per click, cost per application

Adds cost per qualified applicant

Adds outcome based pricing further down the funnel

Work on your side

Expose a feed

Feed plus a tag on the confirmation page

Feed plus API credentials

Feed, API credentials, clean status data

The pattern is simple. Each level gives the platform one more signal, and a platform can only optimize and bill on signals it actually receives. A vendor that offers pay per qualified applicant but only integrates at Level 1 has no reliable way to know who qualified.

Which level do you actually need?

It depends mostly on volume and on how much screening your roles need.

Low volume, specialist roles. If you hire a handful of engineers or finance staff a quarter and your ATS application page already converts well, Level 1 or Level 2 is usually enough. The expensive part of the funnel is sourcing the right people, not processing the application.

High volume, frontline roles. If you hire warehouse associates, drivers, care workers or store staff in the hundreds, Level 3 is the practical minimum. Long ATS application pages lose mobile candidates, and a recruiting team cannot manually sift thousands of applicants. A hosted mobile flow with knockout questions filters before anyone reaches your team, and write-back means nobody retypes candidate data.

Outcome based buying. If you want to pay for qualified applicants, interviews or hires rather than clicks, you need Level 3 at minimum and Level 4 for anything past the screening stage. The billing unit has to be something the platform can observe and you can audit.

A useful rule: choose the lowest level that lets the platform see the outcome you care about. Anything deeper adds setup work without adding value.

What should you ask a vendor to prove?

Ask for a live demonstration on your own ATS rather than a list of logos. Six checks cover most of the risk.

  1. Job sync. Create a test job in your ATS and time how long it takes to appear as a campaign. Then close it and time how long the ads keep running. Google's own job posting guidelines require that jobs "no longer open for applications must be expired," which is a reasonable standard to hold an ad platform to as well.

  2. Write-back target. Submit a test application and confirm it lands in the correct requisition, not a general inbox, with the screening answers attached.

  3. Duplicates. Apply twice with the same email address and see whether your ATS gets one candidate record or two.

  4. Source attribution. Check that the candidate record shows which channel and campaign produced it, so your ATS reports and the platform's reports agree.

  5. Status fields. For Level 4, ask exactly which ATS statuses the platform reads and how often. "We sync hires" is not an answer until you know the field and the frequency.

  6. Channel breakdown. Ask for results per channel, not a blended average, so you can see which channel carries the campaign.

Where do integrations usually break?

Stale feeds. If the feed refreshes once a day, closed jobs keep spending until the next refresh. Ask for the refresh interval and whether closing a job in the ATS stops spend automatically.

Lost attribution at Level 2. Tags on ATS confirmation pages break when the ATS changes its page template or when candidates switch devices halfway through. If application counts in the platform and in the ATS drift apart, this is usually why.

Mapping errors at Level 3. Write-back fails quietly when a job in the platform is mapped to the wrong requisition ID, or when a required ATS field has no matching question in the hosted flow. The candidate exists in the platform but never reaches your team.

Sparse outcome data at Level 4. Hires are rare events compared with clicks, so a campaign that optimizes only on hires may not get enough signal to learn from. Interview scheduled, or a qualified applicant as defined by your own screening, is often the more usable optimization target, with hires used for reporting.

Unclear definitions. If a vendor bills on "qualified" applicants, the definition of qualified should be written into the contract, including who sets the criteria and how disputes work. Otherwise the billing unit is whatever the vendor's dashboard says it is.

How does integration depth change your cost per hire?

Integration depth does not lower media prices on its own. What it changes is where spend is directed. A Level 1 platform optimizing for clicks will find the cheapest clicks, which are not necessarily the people who finish an application or pass screening. A Level 3 or Level 4 platform can shift budget toward the channels and audiences that produce applicants who pass your knockout questions, which is the part of the funnel that decides cost per hire.

It also changes who carries the risk. Under cost per click, you pay for every visitor whether or not anyone applies. Under cost per qualified applicant, the vendor carries the cost of visitors who drop out or fail screening. That shift is only possible when the integration is deep enough for both sides to see the same outcome.

Does Wonderkind combine programmatic advertising with ATS integration?

Wonderkind is a social programmatic job advertising platform that connects to the applicant tracking system a company already uses, which puts it at Level 3 in the model above. Its ATS directory lists 110 systems, including Workday, Greenhouse, iCIMS, SAP SuccessFactors and Bullhorn, and describes the loop as "your roles flow out as campaigns, interview-ready candidates flow back in," with "screening answers attached." Wonderkind's terms describe three modules: Attract for ad creation and distribution, Qualify for application flows and knock-out questions, and Deliver for delivery of candidates to the customer's systems.

The integration is what makes its billing units work. On the pricing page a customer chooses to pay per click, per lead, or per qualified applicant (CPQA), and the terms define a qualified applicant as one who completes the application flow, passes the customer's knock-out questions, meets the configured job-description criteria, and "is delivered into the Customer's ATS," with disputes raised within 10 business days. The trade-off is that the customer sets the qualification bar, so a loose set of questions produces billable applicants who are not worth interviewing.

Frequently asked questions

Is an XML job feed the same as ATS integration?
No. A feed only sends jobs out. Full integration also sends candidates back into the ATS, and ideally reads hiring outcomes so the campaign can learn from them.

Do I need my ATS vendor's help to integrate a programmatic platform?
Usually only for credentials. Greenhouse and Lever both document public APIs for listing jobs and submitting applications, so a platform can connect with an API key that an admin generates.

Can a programmatic platform bill per qualified applicant without ATS integration?
Not reliably. The platform has to observe the screening result and the delivery into your ATS, and you need to be able to audit both.

Which integration level suits high volume hiring?
Application write-back, Level 3, is the practical minimum. It lets candidates apply in a short mobile flow with knockout questions and lands them in the right job in your ATS without manual data entry.

How long does a platform take to pick up a new or closed job?
It depends on the feed refresh interval. Ask the vendor for the number, then test it by opening and closing a test job during the demo.

Never miss a post

Ready to write your own results?

Tell us what you need to hire and we'll show you what Wonderkind can do for your roles.

No credit card required