How Assessment and Background Check Vendors Integrate with ATS Platforms
June 10, 2026
Building native ATS integrations as an assessment or background check vendor means a separate partnership, endpoint stack, and approval process for every ATS.
Greenhouse requires four hosted HTTPS endpoints and polls your test-status endpoint hourly for up to 8 weeks per candidate. Workable's native partner tier requires 15 mutual customers before you qualify. Ashby requires partnership onboarding and credential exchange before customers can connect. Unified APIs — Unified.to and Kombo — abstract these ATS-side assessment APIs behind a single Package → Order → Result flow, so one implementation reaches every supported ATS assessment module. Unified.to additionally abstracts the other side of the same pipeline: background check and verification providers (Checkr, Certn, First Advantage, Socure) through its Verifications API — the only platform covering both directions.
If you sell assessments, skills tests, or background checks, your buyers live in their ATS. The recruiter who orders your coding test does it from inside Greenhouse; the result needs to land back on the candidate's profile in Workable. Being absent from the ATS workflow means being absent from the deal — and being present means integrating with each ATS's partner-only assessment API, one at a time.
This post covers what those integrations actually require, what a unified assessment API abstracts, and where direct partnerships still win.
What each ATS requires from assessment partners
Greenhouse. Assessment partners implement four HTTPS endpoints — list_tests, send_test, test_status, and response_error — and send a sample API key to Greenhouse's partnerships team to begin onboarding. Greenhouse lists your tests in its UI, calls send_test when a recruiter acts, and then polls your test_status endpoint hourly until the assessment completes — for up to 8 weeks per candidate — unless you implement their completion-callback shortcut. You host the endpoints, manage org-level API keys, and maintain Help Center documentation as a partnership requirement.
Workable. Workable's Assessment, Video Interview, and Background Check APIs are partner-only. Native partner status — which brings in-app discoverability and Workable-provided first-line support — requires at least 15 mutual customers and collaboration with Workable's product team. Below that threshold, you build as a third-party partner with lower rate limits and you own all support.
Ashby. Assessment integrations are partnership-mediated: an active partnership is a prerequisite, with base URL and credential exchange during onboarding, and per-tenant API key configuration in each customer's Ashby instance.
Multiply this by every ATS your customers run and the work resolves into four permanent workstreams: partner operations (applications, approvals, marketplace listings), integration engineering (per-ATS endpoints, auth models, polling behaviors, schema quirks), per-customer onboarding (tenant keys, package mapping, stage configuration), and change management (every ATS evolves its API independently, and every change is yours to absorb). Each ATS is not an integration — it's a program.
What a unified assessment API abstracts
A unified assessment API replaces the per-ATS endpoint stacks with one model. On Unified.to, the flow has three parts:
Package — your catalog. You create and update Package objects representing each assessment or check you offer (coding test, psychometric, identity verification), with type, description, scoring range, and regions. Unified surfaces them inside each connected ATS, where they appear as selectable options in the recruiter's own interface.
Order — the recruiter acts. When a hiring team orders your package — manually or triggered by an application reaching a stage — the ATS creates an Order, and it arrives in your system carrying the full context: candidate profile (name, contact, resume URL, identifiers), application, job, and company references. You never create orders; the ATS does. Your application receives them and runs the assessment or check.
Result — you write back. You update the Order with status, score, max score, structured attributes, and report download URLs. The result appears inside the ATS, on the candidate, where the recruiter who ordered it works.
One code path. Across Unified.to's supported ATS assessment modules — Greenhouse, Workable, Ashby, Recruitee, Cornerstone, TalentLyft, and PageUp — the Package and Order objects expose near-identical field coverage (29–31 readable fields per integration, per the published capability matrix), because the abstraction was built to behave identically everywhere. The per-ATS partner mechanics — Greenhouse's four endpoints and hourly polling, the credential exchanges, the schema differences — live inside the integration layer instead of your codebase.
The same flow handles background and verification checks: a "Visa Status" or "SSN Verification" package is ordered and resulted exactly like a skills test.
The platforms that offer this
Kombo is the established specialist for ATS-embedded assessment flows, with 17 assessment connectors including enterprise systems — Workday, SAP SuccessFactors, Oracle Recruiting Cloud, UKG Pro, Avature, iCIMS — alongside Greenhouse, Lever, SmartRecruiters, Ashby, Recruitee, and Teamtailor. Their flow is the same Package → Order → Result model, with an inline-assessment variant for career-page flows and a sandbox for development. Kombo is the right answer when your must-have list is enterprise ATS assessment modules, today.
Unified.to supports seven ATS assessment modules with uniform field coverage, on a pass-through architecture — candidate PII in orders flows through without being stored at rest — and adds the structural difference described in the next section. New ATS assessment modules ship based on customer demand.
Knit provides the primitives — ATS candidate/application sync, stage updates, document upload, score write-back — for assessment platforms to build these flows, without a dedicated package/order abstraction.
Merge is the data-connectivity pattern: assessment vendors like GoodJob use Merge's unified ATS API to reach 50+ ATSes for candidate and application data, while configuring ATS-side assessment partnerships separately where native embedding is needed.
The pipeline has two sides — only one platform covers both
An assessment order and a background check order are the same shape: a package, ordered against a candidate, resulted back into the hiring workflow. But the integration problem runs in two directions, and the platforms above only solve one of them.
The unified assessment APIs — Kombo and Unified.to — abstract the ATS side: they let you, the vendor, embed into many ATSes at once. But if your product consumes checks rather than performs them — you're a screening platform orchestrating background checks, or an assessment vendor adding identity verification to your packages — you face the same per-vendor integration problem on the other side: Checkr, Certn, First Advantage, and Socure each maintain their own APIs and their own per-ATS partner integrations.
Unified.to is the only platform in this comparison that abstracts both: the Assessments API for embedding into ATS pipelines, and the Verifications API for running checks across Checkr, Certn, First Advantage, Socure, Verifiable, and Yardstik through one normalized Request model. A screening platform can receive a recruiter-initiated order from Greenhouse and fulfill it through any connected verification provider — both handoffs through one platform, with no candidate data stored at rest anywhere in between.
Where direct partnerships still win
The honest recommendation is hybrid, and the trade-off is structural.
Direct ATS partnerships win on marketplace presence and depth: an official Workday or Greenhouse marketplace listing is a sales asset, native partner status can bring co-selling and first-line support, and a hand-built integration can use ATS-specific features a normalized layer doesn't model. They cost what they cost: each one is a partnership motion, an endpoint stack, and a permanent maintenance program.
A unified layer wins on coverage, speed, and maintenance: one implementation, many ATSes, connector upkeep absorbed by the platform. It cannot manufacture capabilities an ATS's assessment API doesn't offer, and it doesn't put your logo in an ATS marketplace.
The pattern that works for most assessment and screening vendors: build direct with the one or two ATSes that are strategic to your pipeline — usually where marketplace presence drives deals — and run everything else through a unified layer. Coverage is what loses deals you never see; depth is what wins the deals you're in.
→ Start your 30-day free trial
Frequently asked questions
How do I integrate my assessment tool with Greenhouse?
Two paths. Direct: become a Greenhouse Assessment Partner, implement their four required endpoints (list_tests, send_test, test_status, response_error), and complete partnership onboarding — then maintain that stack as Greenhouse's API evolves. Via a unified API: implement one Package → Order → Result flow on Unified.to or Kombo, and Greenhouse becomes one of several ATS assessment modules reached through the same code.
What is Greenhouse's Assessment API? Greenhouse's partner-only API for embedding third-party assessments into its recruiting workflow. Partners host four HTTPS endpoints; Greenhouse lists the partner's tests in its UI, dispatches them on recruiter action, and polls the partner's status endpoint hourly (for up to 8 weeks per candidate) until completion, unless the partner implements the completion callback.
Kombo vs. Unified.to for assessment integrations? Kombo supports more ATS assessment connectors today (17, including Workday, SAP SuccessFactors, and Oracle Recruiting Cloud) and is the right evaluation for enterprise-ATS-first vendors. Unified.to supports seven ATS assessment modules with uniform field coverage on a pass-through architecture, and is the only platform that also abstracts the verification-provider side — Checkr, Certn, First Advantage, Socure — through the same platform's Verifications API.
Can I run background checks through the same integration? On Unified.to, yes, in both directions: background check packages are ordered and resulted through the same Assessment flow ATSes use for skills tests, and the Verifications API lets your product run checks across multiple background check providers through one normalized Request model — without integrating each provider directly.
Does the candidate data in assessment orders get stored? Not on Unified.to. Orders carry candidate PII — names, contact details, dates of birth, national identifiers — and the pass-through architecture routes that data through to your application without persisting it at rest in the integration layer.