How Assessment and Background Check Vendors Integrate with ATS Platforms

June 10, 2026

Last updated: August 31 2026

Building native ATS integrations as an assessment or background check company means a separate partnership, endpoint stack, and approval process for every ATS.

Greenhouse requires four hosted HTTPS endpoints, at least one mutual customer before it will review your request, and a signed partner agreement. Workable's native partner tier requires 15 mutual customers before you qualify. Ashby requires partnership onboarding and credential exchange before customers can connect. A unified API removes the endpoint engineering by two different routes: a unified assessment API embeds you in the recruiter's own interface but still needs each ATS partnership, and a unified ATS API needs no partnership but writes results back as a note rather than a sortable score.

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 hiring process 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, how the two routes differ, what a unified assessment API abstracts, where the score you write back actually lands, how the platforms offering this compare, and where direct partnerships still win.

What does each ATS require from assessment partners?

Each ATS requires a separate partnership agreement, a hosted endpoint stack, and per-customer credential configuration before your assessments appear in a recruiter's interface. The specifics differ, and none of them are self-serve.

Greenhouse. Assessment partners implement four HTTPS endpoints (list_tests, send_test, test_status, and response_error) and send those URLs plus a sample API key to Greenhouse's partnerships team. Greenhouse lists your tests in its UI and calls send_test when a recruiter acts. When the assessment is done you PATCH the URL Greenhouse gave you, which triggers a status request; polling was deprecated in October 2019 and every implementation since must use that callback. Greenhouse still polls test_status hourly as a backstop, stopping after eight weeks, a complete status, or the candidate being hired. Entry is gated: at least one mutual customer before your request is reviewed, an active website with a privacy policy, a signed Master Partner Agreement, and a review cycle that runs on the first Monday of each month. 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 all 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 commitments: partner operations (applications, approvals, marketplace listings), integration engineering (per-ATS endpoints, auth models, polling behaviours, schema quirks), per-customer onboarding (tenant keys, package mapping, stage configuration), and change management, because every ATS evolves its API independently and every change is yours to absorb. Each ATS is not an integration. It's a programme.

Should you use the Assessment API or the ATS API?

Use the Assessment API when being selectable inside the recruiter's ATS is worth the partnership work, and the ATS API when catalogue coverage matters more than native placement. Most Unified.to customers running assessment flows take the second route.

The Assessment API embeds you in the ATS's own assessment module. Your packages appear as options the recruiter selects, orders arrive from the ATS, and results land as structured data on the candidate record. That placement is the point, and it is what enterprise buyers mean when they ask whether you integrate with their ATS. The cost is that it requires a partnership with each ATS, and dedicated assessment modules exist on a minority of ATS platforms.

The ATS API route needs no marketplace partnership. Your application subscribes to application-updated events, reads the unified status field (which maps every ATS's own stage names onto one set), triggers the assessment when the candidate reaches the stage you care about, and writes the result back into whichever object that ATS exposes. Two targets carry most of this, and neither is universal: as of the published capability matrix in August 2026, Document writes were supported on 40 of 140 ATS integrations and Activity writes on 37. An Activity is a note attached to the candidate or application, visible in the recruiter's ATS without leaving it. A Document is the report itself, a PDF associated with the application. Some ATSes have one and not the other, so check before you design around either. That is roughly three times the number of dedicated assessment modules, but nowhere near the whole catalogue. It also runs the other way on some ATSes: Paylocity Recruiting exposes jobs on a read-only feed and accepts no writes at all, so for a customer on Paylocity the assessment module is the only route in. Check the capability matrix for the ATSes your customers run before assuming either path is available.

A Scorecard is the better target where one is writable, because that is the object the recruiter's own evaluation lives in and it is filterable. You will rarely get the choice. Most ATS platforms block external systems from writing evaluation data: as of the published capability matrix in August 2026, seven ATS integrations in Unified.to's catalogue permitted scorecard writes at all, SmartRecruiters and ATS Anywhere among them, while Greenhouse and Lever both model scorecards with zero writable fields. For the rest, an Activity or a Document is what you have. ATS APIs change constantly, so check the live capability matrix for the current figures.

The honest trade is what the recruiter can do with the result. A structured score written through an assessment module can be filtered and ranked in the ATS. A result written as an activity and a PDF is visible but not sortable. Kombo documents the same trade on its own fallback route. If shortlisting on your score inside the ATS is the outcome you sell, that is the argument for doing the partnership work.

What does a unified assessment API abstract?

A unified assessment API replaces the per-ATS endpoint stacks with one object model and one set of calls. On Unified.to the flow has three parts, and the ATS-facing endpoints each ATS expects are hosted by Unified.to rather than by you.

Package — your catalogue. You create and update Package objects representing each assessment or check you offer: coding test, psychometric, identity verification. The model carries type, description, scoring range, the input questions a recruiter answers when ordering, and per-region availability including cost, currency and expected processing time. How much of that reaches the recruiter depends on the ATS, because each one accepts only what its own partner protocol takes: Greenhouse Assessment, Cornerstone Assessment and Recruitee Assessment accept an id and a name, Ashby Assessment adds a description, and TalentLyft Assessment takes type, description, info URL and regions as well. The package record itself lives in your Unified.to workspace, and the ATS renders whichever fields it supports as selectable options in the recruiter's own interface.

Order — the recruiter acts. When a hiring team orders your package, the ATS creates an Order and it arrives at your system carrying the candidate context that ATS provides: name, contact details, and the ATS reference identifiers it exposes. You never create orders. The ATS does. Your application receives them and runs the assessment or check.

Result — you write back. You update the same Order record with the outcome, so there is no separate result object to create and associate. As of August 2026, status, response_score, and response_url are writable on every ATS assessment module in the catalogue, and they are not all optional: status is required on write for nearly every one, and response_score for most. Those three are the floor: whichever ATS your customer runs, a status, a score and a link to the full result will land. Structured sub-scores, maximum scores and downloadable reports are supported on a subset, so check the integration page for the ATS you're building against before you depend on them.

The write is one-directional. Results go into the ATS and, on almost every ATS assessment module, do not come back out: the Order's readable fields cover the request side and the candidate profile, not the response. Your system stays the record of what a candidate scored.

One code path. Across Unified.to's supported ATS assessment modules, the Package object exposes identical readable field coverage on every integration, because the abstraction was built to behave the same way everywhere. What each ATS accepts on write varies with its own API. Order coverage varies with what each ATS's assessment API actually exposes, so check the integration page for the ATS you're building against. The per-ATS partner mechanics live inside the integration layer instead of your codebase: Greenhouse's four endpoints and completion callback, the credential exchanges, the schema differences.

You never poll for orders. There is no list-orders endpoint in the API at all: /assessment/{connection_id}/order accepts POST only, and every assessment integration page shows no list options for Order, so orders reach you by push or not at all. You register a webhook for assessment_order on the created event, and Unified.to delivers each order to your endpoint with an HMAC-SHA256 signature you validate on receipt. Delivery retries three times immediately and then on a Fibonacci backoff, which is the whole of the recovery path: build your handler to be idempotent. The full sequence, with connection setup and the exact calls, is in How to offer assessment packages and receive orders.

Authorisation varies by ATS, and no two are quite the same. Greenhouse Assessment and Workable Assessment take a Partner API Key. Ashby Assessment adds a customer Ashby API key and a partner ID. Cornerstone Assessment wants the customer's Cornerstone URL, username and password. Recruitee Assessment uses a customer API token and company ID with no partner key at all. PageUp, SmartRecruiters Assessment and Paylocity Assessment use OAuth2 client credentials. PageUp is also the one integration where assessment and ATS access arrive on the same connection rather than two. Budget for per-ATS onboarding: a unified layer absorbs the endpoint engineering, not the credential collection. You create the connection, and your customer configures their ATS to point at https://api.unified.to/assessment/{connection_id}.

The same flow handles background and verification checks. A "Visa Status" or "SSN Verification" package is ordered and resulted exactly like a skills test.

Where does the score actually land when you write it back?

The score you write back is only useful if it reaches the ATS before the recruiter makes the decision, and that depends on whether your integration layer keeps a copy of the ATS's data or reaches the source directly. This is the question the assessment use case turns on and the one most comparisons skip.

On a sync-and-store architecture there is a database between your application and the ATS, and what happens to a write on that path varies by vendor. Some apply it to the source on the call. Others land it in their own store first, and the ATS finds out on the sync cycle. Where that second pattern applies, there is a window in which your product has recorded a completed assessment, the vendor's copy agrees, and the system the recruiter is actually working in does not. A stale read gives someone old information. A pending write gives two systems different answers about the same candidate.

The hiring consequence is specific. A recruiter opens a candidate profile to decide whether to advance them to an interview. The background check cleared twenty minutes ago. If the write is sitting in a synced copy waiting for the next cycle, the recruiter sees an incomplete check and moves on to someone else. Your product did its job and the decision was made without the result.

Unified.to routes each call to the source at request time, and only minimal operational metadata such as identifiers and timestamps persists in its infrastructure. On the ATS-partner integrations there is a second hop worth understanding, because it belongs to the ATS rather than to the integration layer. Greenhouse never accepts the score directly: the partner signals completion with a callback, and Greenhouse then fetches the result itself. Greenhouse's own customer documentation for a live assessment integration says results appear in the partner's portal immediately but may take up to an hour to appear in Greenhouse Recruiting. Whichever integration layer you use, that retrieval behaviour is Greenhouse's, and it sets a floor on how quickly a result reaches the recruiter.

So there are two separate questions, and only one of them is about the vendor you choose. When does your integration layer have the result, and when does the ATS come and get it? Ask any integration layer both. The first is architecture and you can compare vendors on it. The second is the ATS's design, and the thing to establish is whether your integration layer triggers the ATS's immediate-retrieval path where one exists, or waits for the next scheduled poll.

Which platforms offer an embedded assessment API?

Four unified APIs support assessment integration with ATS platforms: Unified.to, Kombo, Knit, and Merge. Three of them publish dedicated assessment endpoints rather than leaving you to assemble the flow from generic ATS primitives, and they differ on coverage, on whether both directions run through one API, and on where your customers' candidate data rests.

Kombo is the established specialist for ATS-embedded assessment flows, running the same Package → Order → Result model with an inline-assessment variant for career-page flows and a sandbox for development. Its published assessment list runs to eighteen ATS modules, weighted to enterprise and staffing systems Unified.to does not reach: Workday, SAP SuccessFactors, Oracle Recruiting Cloud, iCIMS, UKG Pro, Avature, and Bullhorn among them. Six ATSes appear on both catalogues, and Unified.to adds six Kombo does not list, including Workable and Cornerstone.

Read Kombo's connector pages before treating all eighteen as available. As of August 2026, only Workday and SAP SuccessFactors carry no availability note. The other sixteen are published as open beta, closed beta, partner-gated, or requiring a custom plan, and several are more than one: iCIMS and PageUp are closed beta, JazzHR is closed beta and partner-gated. Kombo publishes this on the connector itself, which is more than most of the category does. It also publishes that neither Workday nor SAP SuccessFactors accepts assessment packages through the API, so customers enter them by hand or by CSV in SAP Provisioning.

On data handling, Kombo holds orders, which is a design choice rather than a criticism: an order your endpoint fails to accept stays retrievable, and that is a recovery path Unified.to does not offer. What their assessment documentation does not publish is how long an order is held. There is no stated expiry for an open order, no retention clock after completion or cancellation, and no endpoint to delete an individual order, result, or candidate payload. Their general deletion and logs policies cover integration data and logs, not assessment orders. Since an order carries candidate personal data, that is a question worth asking in writing. The broader architectural comparison is in Kombo vs. Unified.to.

Unified.to covers 17 integrations in its Assessments category, spanning both directions, with identical Package readable coverage across every ATS assessment module. Calls route to the source at request time and no candidate data is stored at rest. New ATS assessment modules ship based on customer demand.

Knit is architecturally the closer peer. Knit's security page states they do not store user data and describes Knit as a pure pass-through proxy, so the custody argument above does not separate the two.

Knit addresses both directions, across two separate API surfaces. Under its ATS API, Knit publishes assessment-partner endpoints for managing assessment packages, reading and updating candidate assessments, and registering ATS assessment partner credentials, so the embedding side has a real abstraction rather than generic primitives. Separately, its Assessment API covers the consuming side across two platforms, Perspect AI and The Predictive Index.

The consuming side is where the two diverge. Knit's Assessment API reference publishes two endpoints: one that lists a platform's assessment types, and one that sends a candidate an invitation with a start and end window. Neither returns a result. On Unified.to the same direction runs through the Order object, which carries the outcome back: status, score, max score, completion time, a result URL, report download links, and structured attributes.

That is the underlying difference. Unified.to runs both directions through one API and one pair of objects, rather than two API surfaces with different capabilities on each.

Merge is the data-connectivity pattern, and it stores a normalised copy of your customers' records until you request deletion. Assessment companies use Merge's unified ATS API, which names 63 ATS integrations, to reach candidate and application data, then configure ATS-side assessment partnerships separately where native embedding is needed. See Merge vs. Unified.to for the custody comparison in detail.

Why does the assessment pipeline run in two directions?

An assessment order and a background check order are the same shape: a package, ordered against a candidate, resulted back into the hiring process. But the integration problem runs in two directions, and most unified APIs solve only one of them. Unified.to's Assessments category covers both, and the direction you get depends on the integration.

Performing assessments. On an ATS assessment module, Package supports the full set of create, list, get, update, and delete. Order always supports update, and a read-back call is the exception rather than the rule: only Greenhouse Assessment and PageUp offer get; the other ten are update-only. You receive the order by push and write to it. You publish a catalogue into the recruiter's ATS and write results back. Twelve of the category's integrations work this way, as of August 2026.

Consuming assessments. On an assessment company such as Berke, The Predictive Index or Wonderlic, the methods are the mirror image: Package is read-only, Order supports get and create with update on some, and the fields you write are the request inputs while the fields you read are the results. You list what that company offers, order an assessment for a candidate, and read the outcome back on the same order. Do not assume the outcome is a number. Berke and Test Partnership return a score and a maximum score; The Predictive Index, whose end-API object is a behavioural assessment, returns status, issue and expiry times and structured attributes; Wonderlic returns status, attributes and report download links. Half of them carry no score field at all, so design for structured attributes and a report link rather than a single value. This direction also needs no partnership: all four authenticate with a token, key or password rather than a partner credential.

Same category, same two objects, opposite direction. A screening product doing both uses one API for both.

The same split applies to background checks, where Unified.to models the consuming side as its own category. If your product orchestrates background checks, or you're adding identity verification to your own packages, you otherwise face the per-company integration problem again: Checkr, Certn, First Advantage, and Socure each maintain their own APIs and their own per-ATS partner integrations. The Verifications API runs checks across Checkr, Certn, First Advantage, Socure, Verifiable, Yardstik, and Harver through one unified Request model. A screening product can receive a recruiter-initiated order from Greenhouse through the Assessments API and fulfil it through any connected background check integration, both handoffs through one API, with no candidate data at rest in between.

Where do direct ATS partnerships still win?

Direct partnerships win on marketplace presence and on depth in a single ATS. A unified layer wins on coverage, speed, and maintenance. The honest recommendation is hybrid, and the trade-off is structural rather than a matter of preference.

Direct ATS partnerships give you marketplace presence and ATS-specific depth. An official Workday or Greenhouse marketplace listing is a sales asset. Native partner status can bring co-selling and first-line support. A hand-built integration can use ATS-specific features a unified model doesn't cover. They cost what they cost: each one is a partnership motion, an endpoint stack, and a permanent maintenance commitment.

A unified layer gives you one implementation across many ATSes, with upkeep absorbed by the integration layer. It cannot manufacture capabilities an ATS's assessment API doesn't offer, and it doesn't put your logo in an ATS marketplace. Where the unified model doesn't reach far enough, Unified.to's Passthrough API is available on the same connection for assessment integrations that support it, with all four methods enabled on Greenhouse Assessment and Ashby Assessment, so an ATS-specific endpoint the assessment model doesn't cover is still reachable without a second integration. The integration page lists whether passthrough is enabled for a given ATS.

The pattern that works for most assessment and screening companies: 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.

How do you choose?

Choose on two axes: which ATS assessment modules your customers actually run, and whether candidate data can rest in a third party. Catalogue size decides less than either.

Kombo fits if Workday or SAP SuccessFactors is a deal-breaker, since those two are generally available on their catalogue and are not on Unified.to's, or per-customer pricing suits your unit economics better than usage-based. Check the availability label on any other ATS you are counting on.

Knit fits if the ATSes and assessment platforms you need are the ones Knit reaches, and you're comfortable running the embedding side and the consuming side as two separate API surfaces.

Merge fits if your requirement is broad ATS candidate and application data rather than embedded assessment ordering, and your compliance review accommodates an integration vendor storing customer data as a subprocessor.

Unified.to fits if you want the Package → Order → Result model without candidate data resting in a third party, you need the background check side abstracted as well as the ATS side, or the ATSes you need are generally available rather than in beta.

One procurement note worth stating plainly rather than leaving to a security review: Unified.to holds SOC 2 Type II and complies with GDPR, CCPA/CPRA, PIPEDA, and HIPAA with BAAs available on Scale. Unified.to does not currently hold ISO 27001. Kombo and Merge do, and Knit claims it on its security page. If ISO 27001 is a hard procurement requirement, that is a real constraint and worth establishing early, and worth asking any vendor for the certificate rather than the claim.

→ Start your 30-day free trial

→ Book a demo

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 Assessment 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 process. Partners host four HTTPS endpoints. Greenhouse lists the partner's tests in its UI and dispatches them on recruiter action. The partner then PATCHes a callback URL to signal completion, which triggers Greenhouse to fetch the result; polling was deprecated in October 2019, so that callback is required for any integration built since. Greenhouse also polls hourly as a backstop, for up to eight weeks per candidate.

Do I need an ATS partnership to write assessment results back? Not on the ATS API route. Writing results back as an Activity plus a PDF Document requires no marketplace partnership, and it works on any ATS integration whose API accepts an activity write, which is a much larger set than the assessment modules. A partnership is required for the Assessment API route, which places your packages inside the ATS's assessment module and returns a structured score the recruiter can filter and rank on.

What happens if my customer's ATS has no assessment module? You use the ATS API route instead. Dedicated assessment modules exist on a minority of ATS platforms, so for the rest you trigger on application status changes and write the result back as an Activity plus a PDF Document, on any integration whose API accepts an activity write. The result is visible on the candidate record but not sortable, which is the trade for reaching an ATS that offers no assessment endpoint at all.

What does an ATS assessment partnership actually involve? It varies by ATS, and none of it is self-serve. Greenhouse requires four hosted HTTPS endpoints, a sample API key sent to its partnerships team, Help Center documentation you maintain, at least one mutual customer before your request is reviewed, and a signed Master Partner Agreement. Workable requires 15 mutual customers for native partner status. Ashby requires an active partnership plus per-tenant API key configuration in each customer's instance. A unified assessment API absorbs the endpoint engineering. It does not remove the partnership itself.

How long does an assessment order stay open? Until you close it. On the direct Greenhouse integration route, Greenhouse polls a partner's status endpoint for up to 8 weeks per candidate. On Unified.to the Order carries no API-enforced expiry: you move it to COMPLETED, FAILED, or REJECTED with an update. There is no delete method, so a cancelled order is a status change rather than a removal.

How do assessment orders reach my system? By webhook push. You register a webhook against the assessment_order object for the created event, and Unified.to delivers each recruiter-initiated order to your endpoint with an HMAC-SHA256 signature and a reference you set at connection time to identify which of your customers it belongs to. You never poll for orders: /assessment/{connection_id}/order accepts POST only, and no assessment integration exposes list options for Order.

Does the candidate data in assessment orders get stored? Not on Unified.to. Orders carry candidate personal data such as names, email addresses, phone numbers, and resume links. Calls route to the source at request time and the response is returned without being retained. Only minimal operational metadata such as identifiers and timestamps is stored, and traffic is processed regionally across US, EU, and AU.