6 Assessment APIs to Integrate With in 2026: Greenhouse, Workable, Ashby

March 11, 2026

Last updated: August 31 2026

Six ATS platforms publish a dedicated assessment API that lets your product appear inside the recruiter's hiring process: Greenhouse, Workable, Ashby, Recruitee, TalentLyft and Cornerstone. None of them are self-serve. Every one requires a partnership application, and most require you to host endpoints that the ATS calls rather than the other way round.

This guide covers what each one actually requires, where the differences bite, and what a unified assessment API changes. Every requirement below comes from the ATS's own developer documentation.

What is an ATS assessment API?

An ATS assessment API is a partner-only interface that lets an assessment or background-check company publish its catalogue into an applicant tracking system, receive orders when a recruiter requests a test, and return results to the candidate's record.

It is not the same as the general ATS API. On Greenhouse, Cornerstone and TalentLyft, the general API carries no assessment object at all. Assessments live on a separate surface with separate credentials and a separate approval process.

Three things distinguish it from an ordinary integration. The direction is usually inverted, meaning you host endpoints and the ATS calls them. Ordering is initiated by a recruiter inside the ATS rather than by your application. And results have a defined destination in the recruiter's interface, which is what makes the integration worth building.

How do the six compare?

Greenhouse Assessment API

Greenhouse runs the most thoroughly documented of the six, and the most inverted. You host four HTTPS endpoints and Greenhouse calls all of them: list_tests returns your catalogue, send_test delivers an order, test_status returns the result, and request_errors is where Greenhouse reports its own failed calls back to you. One call runs the other way, a PATCH to a URL Greenhouse supplies with each order, which you use to signal completion.

Polling is deprecated. Greenhouse deprecated the polling model on 1 October 2019, and every implementation since must use that PATCH callback. Greenhouse still polls test_status hourly as a backstop, stopping when the candidate is hired, when it receives a complete status, or after eight weeks.

Getting in requires a mutual customer. At least one mutual customer must exist before Greenhouse will review your request. You also need an active website with a privacy policy, and a signed Master Partner Agreement. Requests are reviewed on the first Monday of each month, with a response within seven business days, and approved partners get a six-month sandbox.

The result schema is thin. Greenhouse accepts partner_status, partner_profile_url, partner_score and a flat metadata object of JavaScript primitives. There is no maximum-score field, no sub-score structure and no file attachment. If your assessment produces sub-scores, metadata is the only place to put them.

What the recruiter gets is the best of the six. Greenhouse documents that users can view the score, navigate to your site for detail, filter candidates by score, and advance or reject in bulk. Results may take up to an hour to appear in Greenhouse Recruiting.

Background checks have no API. Greenhouse publishes no background-check partner specification. Background-check integrations exist only from the customer's side, through a section on the candidate's Application tab.

Workable Assessment API

Workable publishes three separate partner APIs: Assessment, Video Interview and Background Check. All three are partner-only, and all three are documented apart from the general Workable ATS API.

You host two endpoints under a base URL you supply, one to list your available tests and one to create an assessment. Results go back to Workable.

Two tiers, and the threshold only applies to one. Native Integration Partners need a minimum of 15 mutual customers, get 50 requests per 10 seconds, an in-app listing, and first-line customer support from Workable. Third Party Integration Partners have no mutual-customer requirement, get 10 requests per 10 seconds, and own all support themselves. Workable names unified API providers explicitly as a valid route for that second tier.

Applications are reviewed within a stated 15 days, and Workable expects the build itself to take under 90 days with sandbox access and QA support.

One thing Workable does not publish: whether the Assessment API specifically sits behind the 15-customer native threshold, or is reachable at the third-party tier. The partner page says the dedicated APIs are "exclusively for partner use" without saying which tier of partner. Worth clarifying before you plan around it.

Ashby Assessment API

Ashby's Assessments framework covers skills tests, reference checks and background checks through one surface rather than three.

It is the most genuinely bidirectional of the six. Ashby publishes its own endpoints for you to call, including assessment.start, assessment.list, assessment.update, assessment.cancel and assessment.addCompletedToCandidate, and you host a partner-side API that Ashby calls at a base URL you provide.

The process is a five-stage partnership with a demo at the end. An introduction call, then a legal review, then the build with technical support, then an end-to-end live demo of the integration to Ashby's team, then marketplace go-live and inclusion in their monthly customer newsletter.

No threshold and no timeline are published. Ashby states no minimum customer count, no revenue bar and no duration for any stage. The only stated eligibility bar is that they want to see a built solution before the conversation gets serious. The sandbox they provide at stage two has no public documentation at all.

Recruitee Assessment API

Recruitee calls it the Partners API, and it runs on its own hostnames separate from the main ATS API. Assessment is a first-class type: partner.kind is an enum of assessment, background_check and reference_check, and the only difference between them is the label the recruiter sees, "Send test" against "Request background check".

Results are carried by a dedicated Report entity rather than being bolted onto candidate notes or attachments. You create a report, then patch it with status, score and URLs as the assessment progresses.

Ordering is manual only. This is the single most consequential difference in the six. Recruitee's own FAQ states that assessments can only be sent manually and that automated actions are on the roadmap with no date. If your product depends on triggering an assessment when a candidate reaches a stage, that does not exist on Recruitee. Recruitee also sends no email to the candidate, so candidate communication is entirely yours.

Recruitee controls when you go live. Development is confined by rule to their Release Candidate environment. Your partner record carries a promoted flag set to false, making you visible only to your own company, and Recruitee's team copies it to production and promotes it when they are satisfied. No review turnaround is published. The only timing figure Recruitee offers is an anecdote that some partners finished development in three days.

TalentLyft Assessment API

TalentLyft's Partner API has a documented assessments specification: you host a tests endpoint and an assessments endpoint, TalentLyft supplies a callback URL per order, and you push the result back to it.

The result schema is unusual. TalentLyft accepts Status, ResultsUrl, Score, Grade, Summary, Duration, Details and Attachments. Score is a string capped at 250 characters with a stated preference for a percentage, not a number with a scale, and there is no maximum-score field. Grade is a fixed enum of Poor, BelowAverage, Average and Superior. Details accepts JSON nested two levels deep, which is where sub-scores would have to go. Attachments accept PDF, DOC and DOCX up to 20MB.

The recruiter sees an activity feed, not a filterable field. Results appear on the candidate's activity feed with a downloadable report, plus a status indicator beside the candidate's name that a recruiter hovers over. TalentLyft does not publish whether the returned score or grade becomes a sortable or filterable candidate attribute, and their customer API exposes no assessment field on the candidate object.

Background checks are named but not specified. The Partner API reference lists Background checks as a category, but that page carries only conceptual prose. No endpoints, no fields, no payloads.

Nothing about the application is published either: no eligibility criteria, no review process, no timeline, and no visible form fields on the partner programme page.

Cornerstone Assessment API

Cornerstone's assessment surface is the Assessment Connector, part of its Edge connector family, and it is not part of the Recruiting REST API. There is a matching Background Check Connector.

One vendor per portal. This is the constraint that matters most and it has no equivalent among the other five. Cornerstone's developer guide states plainly that only one assessment vendor can be integrated in a portal using the connector, and the same applies to background checks. Your customer cannot run you alongside a competitor. If they already have someone, replacing them is the only way in.

There are two mechanisms, and only one is documented. Alongside the connector, Cornerstone supports "External Assessment" as an application workflow item, keyed on a vendor-supplied solutionID. That path supports automatic disposition, where applicants scoring below a configurable threshold are moved to a Closed status with a Failed Pre-Screening disposition. The technical contract behind solutionID is not published.

Access runs through the customer or through partnership. Either your customer submits a purchase inquiry from the Edge Marketplace inside their portal, or you apply as a Technology Partner. No threshold, timeline or partner fee is published. Connectors are free to Cornerstone's clients, but the production API price is not published. A separate commercial contract between the customer and you is also required.

Auth is per tenant with no global partner credentials. Cornerstone calls your endpoints using HTTP Basic credentials that the customer types into their own portal.

The recruiter gets a sortable column. Cornerstone documents a per-assessment column on the Manage Applicants table carrying score and result, named after the assessment, permission-gated, and explicitly sortable. Whether it is filterable is not published.

What makes assessment integrations hard?

Four things, and none of them are the API call itself.

The direction is inverted. On five of the six, you host a web service the ATS calls on its own schedule. That is an availability commitment, not a client library. Your uptime becomes their integration's uptime.

Every result schema is different, and most are lossy. Greenhouse takes a number and a flat metadata object. TalentLyft takes a string and a four-value grade. Recruitee takes a Report entity. Cornerstone takes score plus result. If your assessment produces sub-scores, competency breakdowns or banded results, each ATS will flatten them differently, and on some of them the recruiter cannot sort on what you send.

Ordering models differ in kind, not just in detail. Greenhouse ties ordering to an interview stage. Recruitee supports manual sending only. Cornerstone has two separate mechanisms with different capabilities. A product built around stage-triggered assessments works on some of these and not others.

Partnership is the real gate. Greenhouse wants a mutual customer and a signed agreement before it reviews you. Workable's native tier wants fifteen. Ashby wants a live demo. Recruitee decides when you are promoted to production. Cornerstone lets your customer have exactly one of you. None of that is engineering, and none of it goes away because you chose a good API client.

What does a unified assessment API change?

A unified assessment API replaces the per-ATS endpoint stacks with one object model. 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 is your catalogue. You create Package objects for each assessment or check you offer, and Unified.to surfaces them inside each connected ATS as options the recruiter selects.

Order is the recruiter acting. The ATS creates the order and it arrives at your system by webhook push, carrying the candidate context that ATS provides. You never create orders on the ATS-embedded route.

Result is you writing back. You update the same Order record with the outcome. There is no separate result object to create and associate.

Across every ATS assessment module in Unified.to's catalogue, status, response_score and response_url are writable, so a status, a score and a link to the full result will land whichever ATS your customer runs. Structured sub-scores, maximum scores and downloadable reports are supported on a subset, so check the capability matrix for the ATSes your customers use.

What a unified layer does not remove is the partnership. Greenhouse still wants its mutual customer. Ashby still wants its demo. Cornerstone still allows one vendor per portal. The endpoint engineering, the per-ATS schema differences and the ongoing maintenance move into the integration layer; the commercial gate stays where it is.

For the full comparison of unified assessment APIs, including Kombo, Knit and Merge, see How assessment and background check vendors integrate with ATS platforms.

→ Start your 30-day free trial

→ Book a demo

Frequently asked questions

Which ATS platforms have a dedicated assessment API? Six publish one with enough documentation to build against: Greenhouse, Workable, Ashby, Recruitee, TalentLyft and Cornerstone. Workable and Ashby also cover background checks through the same partner surface, Recruitee treats background checks and reference checks as sibling types of the same integration, and Cornerstone has a separate Background Check Connector. Greenhouse publishes no background-check partner API at all.

Can I trigger an assessment when a candidate reaches a pipeline stage? It depends on the ATS. Greenhouse ties the assessment to an interview stage, where the recruiter then clicks Send Test. Recruitee supports manual sending only and states that automated actions are on its roadmap with no date. Cornerstone's External Assessment path supports automatic disposition on score. If stage-triggered assessment is central to your product, verify it per ATS rather than assuming.

Do I have to host endpoints for an ATS assessment integration? On five of the six, yes. Greenhouse, Workable, TalentLyft and Cornerstone call endpoints you host. Ashby and Recruitee run in both directions, with a partner-hosted API alongside endpoints they publish for you to call. That makes your service's availability part of their integration, which is a different commitment from consuming an API.

How many mutual customers do I need before an ATS will work with me? Greenhouse requires at least one before it will review your request. Workable requires 15 for its native partner tier, though its third-party tier has no such requirement. Ashby, Recruitee, TalentLyft and Cornerstone publish no quantified threshold at all.

Can two assessment companies integrate with the same ATS customer? On Cornerstone, no. Its documentation states that only one assessment vendor can be integrated in a portal through the connector, and the same limit applies to background checks. The other five publish no such restriction.

Will the recruiter be able to sort candidates by my score? Greenhouse and Cornerstone both document a structured score the recruiter can act on, with Greenhouse also documenting filtering and bulk advance or reject. Cornerstone's column is sortable but filtering is not published. TalentLyft surfaces results on the activity feed with a hover status indicator and does not publish whether the score becomes a sortable attribute. This is worth establishing early, because a score a recruiter cannot rank on is a materially weaker product.

Author

Written by Mallory Greene

Mallory Greene is Head of Marketing at Unified.to. She writes about integration infrastructure, unified APIs, and MCP for technical teams. Based in Toronto.