How to Test a Programmatic Platform's ATS Integration Before You Scale Spend: A Two-Week Plan

Yes, several platforms combine programmatic job advertising with ATS integration, but the claim on an integrations page tells you only that a connector exists. It does not tell you whether jobs leave your ATS cleanly, whether every applicant lands in the right requisition with their screening answers, or whether the number you are billed on matches the number your ATS shows. The way to find out is a short acceptance test run before you scale spend. This guide lays out a two-week plan with five checks, each with a pass mark, that a talent acquisition or HR operations lead can run with one recruiter and one ATS administrator.

Our comparison of the four ATS integration levels explains what each level lets a platform see and bill on. This piece is the practical follow-up: how to prove which level you actually bought.

Why test the integration instead of trusting the integrations page?

Because most integration failures are silent. A job feed that stops updating does not throw an error in your inbox. An application that fails to post into the ATS simply never appears, and nobody looks for a candidate they do not know exists.

The ATS vendors document these failure modes themselves. Lever's public postings API, which job sites use to submit applications, states that "Application create requests are rate limited" and returns a 429 error above 2 application requests per second. The same documentation tells integrators they must queue and retry those requests, or applicants can be lost. On a Monday morning after a weekend campaign, two requests per second is not a high ceiling.

Versions matter too. Greenhouse's developer documentation states that the Harvest v1/v2 API "is deprecated and will be removed on August 31, 2026", with integrators directed to Harvest v3. A connector built on the old version and never migrated is exactly the kind of problem a logo on a partner page will not reveal.

What does a two-week ATS integration test cover?

Five checks, in the order the data flows. Run them on a small, real campaign: for example, 10 open roles at one warehouse site in Columbus, Ohio, with a fixed test budget agreed in advance.

The pass marks above are a suggested starting point, not an industry standard. Agree yours with the vendor before day 1 and write them into the pilot order.

Days 1 to 3: Do jobs leave the ATS correctly, and come down when filled?

Start with the feed, because everything downstream depends on it. Open three roles in the ATS on day 1 and close one role you know is live. Then check four things on the platform side: the new roles appear, the title, location and pay match the ATS exactly, the closed role stops serving ads, and any edit you make to a live role (a pay change is the best test) carries through.

Expiry is not cosmetic. Google's job posting guidelines say that "Failure to take timely action on expired jobs may result in a manual action" against the site, and they require datePosted, description, hiringOrganization, jobLocation and title on every posting. A programmatic platform that keeps paying to advertise a filled job wastes budget and frustrates the candidates who apply to it.

Days 3 to 5: Does every test application land in the right requisition?

Have a recruiter submit 20 test applications across at least three roles and two channels, using clearly labeled test names. Mix the cases: a complete application, one that fails a knock-out question, one with a phone number but no email, and one submitted twice by the same person.

Then check the ATS record by record. You are looking for four things:

1. Placement. Each candidate sits on the correct requisition, not a general talent pool.

2. Screening data. Knock-out answers are attached to the candidate record, so a recruiter does not have to ask the same questions again.

3. Required fields. Lever's documentation notes that "Two fields are required by our system in order to create a candidate: name and email address", and administrators can make more fields required. If the platform's form collects less than your ATS requires, those applicants fail to post.

4. Duplicates. The repeat applicant is merged or flagged according to your ATS rules, not created twice.

Twenty out of twenty is the pass mark. Nineteen out of twenty means 5% of real applicants could go missing at scale, so ask for the root cause before moving on.

Days 5 to 8: Is the source credited correctly?

If the ATS cannot tell which applicants came from the platform, you cannot measure cost per hire by source, and the platform's own dashboard becomes the only record. Most ATSs have a field for this. Greenhouse's API, for example, includes a source_id described as "The id of the source to be credited for this application", and Lever's postings API accepts a source tag such as "LinkedIn".

Check that every test applicant carries the platform as source. Then check whether the channel detail survives (Meta, TikTok, Google, a job board), either as a sub-source or a tag. Channel detail is what lets you see, inside your own system, which channel produced candidates who were hired rather than candidates who only applied.

Days 8 to 10: Does a status change in the ATS reach the platform?

This is the check that separates a delivery pipe from an outcome loop. Move three test candidates through your stages: one to interview, one to rejected, one to hired. Then ask the vendor to show you, in their system, that the change arrived.

The ATS side of this is well documented. Greenhouse publishes webhooks for candidate stage changes, rejections and hires, and it notes that "The Hire Candidate event occurs when an offer is accepted". Ad channels can accept outcome data back as well: Google Ads offline conversion imports exist so you can "measure what happens in the offline world", and Meta's Conversions API connects an advertiser's own data, including CRM records, to Meta's delivery system.

A vendor that does not read status back is not failing the test, as long as they say so plainly. What fails is a vendor who claims optimization toward hires but cannot show the hire event arriving.

Days 10 to 14: Does the billing report reconcile with the ATS?

Pull the platform's billing report for the test period and match it line by line against the ATS. The question is simple: for every unit you are billed on, can you find the corresponding record in your own system?

How hard this is depends on the billing event. A click lives only in the channel's logs, so you cannot reconcile it against the ATS at all. A lead form submission can be matched if the lead was delivered. An outcome such as a qualified applicant delivered into the ATS can be matched one to one, which is the strongest position for a buyer.

Check the dispute terms while you are at it. If the contract gives you a fixed window to challenge a billing report, your reconciliation has to finish inside it, so schedule it as a recurring task, not a one-off.

What counts as a pass overall?

Score each of the five checks pass, partial or fail. A reasonable rule for scaling spend:

• Feed and delivery must pass outright. These two decide whether candidates exist in your system at all.

• Source credit can be partial if platform-level source is correct and channel detail is on the vendor's roadmap with a date.

• Status read-back can be "not offered" if the vendor said so before the test and does not bill on hires.

• Reconciliation must pass for whatever event you are billed on.

Record the results in the same sheet you used to set the pass marks, signed off by the recruiter and the ATS administrator. That sheet becomes the baseline for the next quarterly review.

Can Wonderkind be tested this way?

Yes. Wonderkind is a programmatic social job advertising platform whose ATS directory lists "110+ applicant tracking systems, one integration layer", including Greenhouse, Lever, Workday and iCIMS, and states that "Verified, qualified candidates land in the right vacancy in your ATS, with their screening answers attached." That maps directly to the day 3 to 5 check. On pricing, buyers choose to pay per click, per lead or per qualified applicant (CPQA).

The CPQA option is what makes the day 10 to 14 reconciliation clean. Wonderkind's terms define a qualified applicant through four conditions, the last being that the candidate "is delivered into the Customer's ATS", and allow disputes "within 10 business days of the relevant dashboard report." The trade-off is that the directory describes delivery into the ATS, not status read-back, so ask how hiring outcomes flow back before you plan the day 8 to 10 check, and remember that CPQA quality depends on the knock-out questions you configure.

Frequently asked questions

How long should an ATS integration test take?

Two weeks is enough for most employers: three days for the job feed, about a week for delivery and source checks, and the remaining days for status and billing reconciliation. Large multi-country ATS setups may need a separate test per instance.

Who needs to be involved?

One recruiter to submit test applications and move candidates through stages, and one ATS administrator who can see field mappings, sources and API logs. The vendor's integration contact should attend the day 1 kickoff and the day 14 review.

Which failure is hardest to spot?

Silent delivery loss: applications that never reach the ATS because of missing required fields, rate limits or an outdated API version. It is invisible unless you count test applications on both sides.

Should we test with real candidates or test applications?

Both. Test applications cover edge cases on demand, such as knock-out failures and duplicates. A small live campaign shows whether the feed, source credit and billing hold up under real volume.

Does a deeper integration always mean better results?

No. A deeper integration gives the platform more signal to optimize on and gives you a cleaner audit trail, but results still depend on the job content, pay and how fast recruiters respond to delivered candidates.