Best Unified API for ATS Integrations in 2026

June 10, 2026

Updated July 2026

Unified.to is the only unified API that publishes, per integration, exactly which fields you can read and write and which events fire — for every one of its 112 ATS integrations, before you write a line of code. It runs on a pass-through architecture that stores no candidate data at rest, and its ATS surface reaches background checks, assessments, and job boards through the same connection, where most unified APIs model those as a separate product, if at all.

That matters because recruiting integrations don't fail on the read path — they fail on the write path, and the write path is the exact thing most unified APIs won't document until you're already building. Merge (63 named ATS integrations, sync-and-store) is the most mature enterprise option; Kombo has the deepest European ATS list; Apideck, Knit, and Truto fit narrower shapes. The right choice depends on which objects you need to write, on which specific ATS platforms — and whether the vendor tells you the answer before you sign, or after.

Why do ATS integrations fail on the write path, not the read path?

Recruiting products rarely fail at reading ATS data — they fail at writing it back. Reading candidates and jobs from Greenhouse or Lever is the easy half of the integration. The hard half is the write path: pushing a sourced candidate into your customer's ATS, moving an application to the next stage, submitting evaluation data after an interview.

Every ATS enforces different write rules — some objects are read-only, some allow create but not update, some have no writable fields at all — and most unified APIs abstract over those rules instead of documenting them. Teams discover the gaps at month 3, after the feature is committed to a customer, not during evaluation.

If your primary requirement is ATS coverage breadth, the choice is made before you evaluate any vendor. Unified.to offers two paths for assessment use cases: the ATS API, which triggers on application status changes and writes results back as activities across the full ATS catalog with no marketplace partnership required, and the Assessment API, which embeds directly into the recruiter's ATS workflow but is limited to a smaller integration set and requires a partnership arrangement. Most customers use the ATS API path. The rest of this post covers that path.

This post compares the unified API platforms that support ATS integrations — Merge, Kombo, Apideck, Knit, Truto, and Unified.to — on the dimensions that determine whether your write-dependent features ship: object coverage, write support, event delivery, and where the data actually flows. Every Unified.to number in this post comes from our published ATS integration matrix, which lists readable fields, writable fields, required fields, webhook events, and list parameters for every integration.

Can a unified API write to any ATS?

Every unified API in this comparison can write to ATS platforms, but that answer is nearly meaningless — write constraints are a property of the underlying ATS APIs, not of the unified layer on top of them. Greenhouse provides scorecard objects with no writable fields. Workable's jobs are read-only. No unified API can override those constraints, and any platform implying uniform write support across its catalog is describing its schema rather than what each integration actually permits.

The most common assessment integration flow looks like this: your application listens for an updated application event, checks the unified status field — which maps vendor-specific stage names (first interview, second interview, background check, hired, rejected, and the rest) into one consistent set across every integration — triggers the assessment when the right status is reached, and writes the result back to the ATS. The status field is readable and unified across all integrations. It is not writable by design: ATS platforms control their own pipeline transitions.

The questions that actually predict whether your features ship:

• Which objects support writes, on which specific ATS integrations?
• Which objects emit change events, and how are events delivered when the ATS has no native webhooks?
• Does the platform publish those answers, or do you find out during implementation?

That last question separates the vendors more than any feature does.

Which unified APIs support ATS integrations?

Unified.to supports 112 ATS integrations behind nine unified objects, with a published capability matrix covering readable fields, writable fields, required fields, webhook events, and list parameters for every integration. The rest of this post shows what that looks like in practice.

Merge has the deepest ATS object model after Unified.to — candidates, jobs, applications, interviews, scorecards, attachments, offers, screening questions — across 63 named ATS integrations. Merge publishes the third-party endpoints it accesses per integration, from which read and write support can be derived; independent reviews describe write depth as strongest on candidates, applications, and attachments, and provider-dependent elsewhere. Architecture is sync-and-store: per Merge's own documentation, synced data is stored in its infrastructure until explicitly deleted, reads hit that stored copy, and freshness is bounded by the sync schedule. Merge is the right answer when operational maturity and HRIS-adjacent depth outweigh live source reads and field-level write transparency.

Kombo is the HR vertical specialist, with the deepest European ATS coverage in this comparison and a model centered on jobs, candidates, applications, attachments, and users. Kombo publishes 250+ integrations across its future-of-work categories, with 114+ on the ATS side, but offers no public capability matrix — write limitations on specific integrations are clarified during sales evaluation. Architecture is sync-and-store: per Kombo's own documentation, data is mirrored into its database and reads are served from that store, on a cadence that depends on your plan, with a notification webhook telling your application to fetch the updated records. Kombo is the right answer for EU-heavy recruiting products that prefer reads against a stored copy.

Apideck deserves credit on transparency: each integration page lists exactly which operations (list, get, create, update, delete) each object supports. The ATS model is narrow — jobs, applicants, applications, with no first-class interviews, scorecards, documents, or offers — across roughly 11 ATS integrations. Apideck shares the pass-through posture (no cached customer data), but provides no managed change detection: virtual webhook polling defaults to every 24 hours, and faster cadences are plan-dependent. Apideck is the right answer when your ATS needs fit three objects and an embedded marketplace UX matters more than event delivery.

Knit is a genuine architectural peer — pass-through, no stored user data, webhook-driven delivery across roughly 40 ATS integrations. Its webhook-push model streams initial and delta syncs to your webhook endpoint, which means your application owns ingestion, ordering, and idempotency. The unified ATS model centers on jobs and applications with candidates nested inside; no public capability matrix. Knit is the right answer for HR-leaning products that want a pass-through, webhook-driven architecture. (Its free Launchpad tier covers MCP servers and a capped call volume; the unified API itself is a paid plan.)

Truto publishes its integration and resource counts — roughly 27 ATS integrations and 17 normalized resources — treating catalog disclosure as a feature, the way Apideck treats operation-level support as one. Its differentiator is per-tenant schema customization through JSONata transforms. The catalog is smaller and Lever support is currently flagged beta on their marketplace. Truto is the right answer when deep per-tenant schema control matters more than catalog size.

What does Unified.to's ATS capability matrix show?

The unified ATS model defines nine objects — Candidate, Job, Application, Application Status, Interview, Document, Scorecard, Company, and Activity — spanning 139 readable properties, with published writable and required-field counts and webhook event types for every one of its ATS integrations. Because ATS APIs change constantly — Unified.to's changelog recorded over 370 field additions across the catalog in the three months to July 2026, including new readable fields on Greenhouse in that window — the live integration matrix is the canonical source for current counts. The figures below are a snapshot at time of writing, not a substitute for the matrix.

Those 139 readable properties break down by object as: Job 27, Candidate 26, Activity 20, Application 17, Interview 12, Document 11, Scorecard 11, Company 10, and Application Status 5 — the enriched-object design in numbers, with related data carried on the parent rather than split across separate resources.

Field coverage is uneven across integrations, because ATS APIs are uneven. On widely used systems, the readable and writable fields available through the unified model:

Every number in those two tables is a fact Unified.to can state because it measured it — and a fact most competitors leave you to discover in production. Read the scorecard row as the example that explains the whole category: only seven ATS integrations support scorecard writes. The cause sits in the ATS platforms themselves — most don't allow external systems to write evaluation data — not in the unified layer. Greenhouse and Lever both model scorecards with zero writable fields. When a vendor omits this row, the constraint doesn't disappear; it just becomes your problem at month three, after the feature is sold.

The same logic applies to interviews and to application status — readable across 39 integrations for triggering, but list-only for writes across the unified model, because ATS platforms control status transitions through their own pipeline rules.

How do you write assessment results back to an ATS?

You write assessment results back to an ATS as an activity, not a scorecard — a note attached to the candidate or application that appears directly in the recruiter's ATS, visible without leaving their system. Scorecards are reserved for human evaluators, and most ATS platforms block external systems from writing them: only seven of the catalog's ATS integrations permit scorecard writes at all. Activities have no such restriction, which is why every Unified.to customer running an assessment flow writes results back as activities.

The accompanying report is handled by the Document object: you provide the URL of the report stored on your system, Unified.to transfers it to the ATS, and associates it with the application or candidate ID. Practically all ATS integrations accept documents as PDFs only.

That answers the question from the recruiting product's side — you're consuming an assessment result and landing it in the ATS. The mirror-image case — you're the assessment or background-check vendor trying to embed into many ATSes at once — runs through Unified.to's Assessments API, a Package → Order → Result flow that reaches a set of ATS assessment modules through one implementation. That's a distinct write path from the scorecard object: the assessment modules accept structured results through their own assessment endpoints, which is why an assessment vendor can write back to an ATS whose scorecard object is otherwise read-only. That side is covered in depth in how assessment and background check vendors integrate with ATS platforms.

Event coverage follows the same pattern — 23 webhook event types across the catalog, with job and candidate events broadly emitted and interview and scorecard events rare, because the underlying platforms rarely surface them:

One design note for readers comparing object models: offers are modeled within the Application object rather than as a standalone object, with full compensation, status, and lifecycle date fields. An offer doesn't exist outside an application, and the model reflects that.

On some systems — Greenhouse among them — offer data requires a separate upstream call per application, so Unified.to marks it a slow field: excluded from the default response, included when you ask for it. You choose completeness or latency per request, rather than paying for the extra call on every read or assembling it yourself from a second object.

Why does object design show up in your build time?

Object design isn't a schema preference — it's a count of how many calls your features take. When a platform models every related concept as its own first-class object — screening questions, tags, interviews, offers, rejections each standing alone — a single "show me this application" view becomes several API calls stitched together in your code. The checklist looks comprehensive in a sales comparison; the integration is where you pay for it.

For a concrete measure: Merge's ATS model has 17 objects and Truto's has 17, each surfacing offers, reject reasons, tags, and screening questions as separate resources. Unified.to embeds those into nine objects: offers, answers, and rejection data are fields on the Application; screening questions, postings, and openings are fields on the Job; tags live on the Candidate; notes live in Activity. One call returns the enriched object, not a join you assemble yourself. (Interview is its own object, keyed to the application — the exception that proves the rule: it exists independently because an interview genuinely does.)

"Our competitors customers make five API calls to assemble the same data you get from one of ours. We've done the unification so you don't inherit that complexity." — Roy Pereira, CEO, Unified.to

Fewer calls, fewer moving parts, less to maintain as each underlying API changes. The cost of the many-objects path isn't visible on day one — it shows up as build time, latency, and the maintenance load of every extra call, which is easy to under-weight when AI coding tools make the first version feel fast. The complexity you don't see is still complexity you took on.

How do unified APIs deliver ATS data: pass-through vs. sync-and-store?

On a pass-through architecture, a write executes against the source ATS at request time. The ATS confirms or rejects it immediately, and your application knows the result before the request returns. There is no intermediate database between your write and your customer's system, and no copy of their candidate data sitting in vendor infrastructure.

On sync-and-store architectures, a database sits between your application and the ATS. Reads return the stored copy, with freshness bounded by the sync schedule. Candidate records — PII by definition — persist in the vendor's infrastructure, which your customers' security teams will evaluate as part of their compliance scope.

Event delivery is where the architectures diverge most for ATS use cases, because most ATS platforms don't offer native webhooks. The fallback model matters:

When an ATS does provide native webhooks, Unified.to passes those events through directly, with the same payload format and the same subscription interface as virtual webhooks. Your application code doesn't branch on which delivery path an integration uses.

What integrations does a recruiting product need after the ATS?

A candidate doesn't live in one ATS — they move through systems. Sourced into the ATS, assessed mid-pipeline, background-checked before the offer, hired into the HRIS, onboarded into training. Each handoff is an integration boundary, and most platforms in this comparison stop at one or two of them.

Unified.to covers the lifecycle as adjacent unified API categories on the same platform: HR & Directory (297 integrations, where hired candidates become employees), Verifications (Checkr, Certn, First Advantage, Socure, Verifiable, Yardstik — background checks as a first-class category, which no other unified API in this comparison models separately), Learning Management (onboarding and training systems), and Assessments — which runs in the other direction: it lets assessment and screening vendors embed into ATS pipelines, receiving recruiter-initiated orders from Greenhouse, Workable, Ashby, and others and writing results back into the ATS.

For a recruiting product, that means the integrations after the hire — and the vendors plugging into the same pipeline — run through the same platform, the same authorization components, and the same pass-through architecture as the ATS integrations. Every other vendor in this comparison makes you add a second provider to cross that boundary. The product you're building rarely stops at the ATS; the integration layer under it shouldn't either.

How fast can you ship ATS integrations with a unified API?

Sync2Hire builds post-application workflows for recruiting teams — a product that lives or dies on consistent application and candidate data across whatever ATS each customer runs. ATS is a category where normalization matters enormously: every system models candidates, jobs, and applications differently, and post-application workflows depend on one consistent shape.

Working with Unified.to, Sync2Hire shipped 19 ATS integrations in two weeks, writing one set of ingestion logic against the unified ATS objects instead of mapping each ATS individually. The capability matrix did the evaluation work the sales process usually hides: they knew which integrations supported which writes before committing features to customers.

How do you evaluate a unified ATS API?

Six questions, regardless of vendor:

1. Is the capability matrix public? If write support per object per integration isn't published, the answer is being managed, not documented — you'll learn it during implementation.
2. Which objects can you write, on the specific ATS platforms your customers use? Candidate writes are broadly supported. Scorecards, interviews, and offers are not — on any platform — because the underlying ATS APIs restrict them. Get the per-integration answer in writing.
3. What happens on integrations without native webhooks? Ask for the default polling cadence, whether it's tier-gated, and whether events include the changed data or just a notification. The answers range from every minute to every 24 hours across this field.
4. Where does candidate data rest? Pass-through architectures keep PII out of the integration layer entirely. Sync-and-store architectures put the vendor inside your customers' compliance scope. Neither is wrong; one of them extends your enterprise security reviews.
5. What does month 3 look like? ATS APIs change, write rules shift, and new integrations get requested by customers you haven't signed yet. The maintenance question — who absorbs that drift — is the question the first demo never covers.
6. If an ATS your customer needs isn't in the catalog, what happens next? On most platforms the answer is a feature request into someone else's roadmap. Unified.to adds new integrations from customer demand, with a visible roadmap you can move your own request up — its customers report new integrations added within days.

The first question decides the rest. If a vendor won't publish write support per object per integration, every other answer is whatever it needs to be to close the deal — because you have no way to check it until you've built against it. The vendors in this comparison split cleanly on that line: Unified.to and, at the operation level, Apideck and Truto publish; the rest resolve it in a sales call.

Unified.to's answers are already public: 112 ATS integrations, the full readable/writable/required-field matrix, virtual webhook change detection configurable to every minute, and a pass-through architecture with no customer ATS records at rest. You can evaluate it against the exact ATS platforms your customers run — today, without a sales call — because the matrix was built for that. That is the whole argument: the answer to "will this work for my customer's Greenhouse instance" should be a lookup, not a leap of faith.

Start a free 30-day trial or book a demo.

Frequently asked questions

Which unified API supports the most ATS integrations? Kombo publishes the largest ATS catalog at 114+ integrations, with the deepest European coverage. Unified.to publishes 112, Merge names 63, Knit roughly 40, Truto roughly 27, and Apideck roughly 11. Unified.to's differentiator is reach through a single connection rather than raw catalog size: background checks, assessments, and job boards run through the same ATS integrations, where Kombo splits them into a separate API.

Do unified APIs support writing to ATS platforms like Greenhouse and Lever? Yes, within the limits of each ATS's API. On Unified.to, Greenhouse supports 42 writable fields and Lever 29 across the unified ATS objects. Some objects are read-only by the ATS's design — Greenhouse and Lever scorecards, for example, have no writable fields on any platform.

How do I write assessment or screening results back into an ATS? Write them back as an activity — a note attached to the candidate or application inside the recruiter's ATS — rather than as a scorecard, which most ATS platforms block external systems from writing. On Unified.to the accompanying report is transferred as a PDF Document and associated with the candidate or application. Assessment and background-check vendors embedding into ATS pipelines use the separate Assessments API, a Package → Order → Result flow that reaches ATS assessment modules through one implementation — a distinct write path from the scorecard object, which is why it works even where the scorecard is read-only.

Which unified API supports scorecard writes? Scorecard writes are restricted by the ATS platforms themselves — most don't allow external systems to write evaluation data. Unified.to documents scorecard write support on seven ATS integrations in its published capability matrix — the small share whose APIs permit external evaluation writes. No unified API can offer broader scorecard write coverage than the underlying ATS APIs allow.

How do unified APIs handle ATS platforms without native webhooks? Approaches differ by architecture. Unified.to runs managed change detection at a configurable interval (as frequent as every minute) and delivers events with the changed records included. Sync-and-store platforms poll into their own database — Kombo on a plan-dependent cadence, Merge on its sync schedule — and notify your application to fetch the updated records. Apideck's virtual webhook polling defaults to every 24 hours.

Does Unified.to store candidate data? No. Unified.to is a pass-through architecture: requests route to the source ATS at request time, and no customer ATS records are stored at rest. Only credentials and minimal operational metadata persist, with customer-managed secret options available on the Pro tier and above.

Which unified APIs cover background checks and assessments alongside ATS? Unified.to models Verifications (Checkr, Certn, First Advantage, Socure, Verifiable, Yardstik) as its own unified API category alongside ATS, HR & Directory, Learning Management, and Assessments. Kombo includes assessment and background check within its HR-vertical scope. Knit offers a unified assessment API. Merge and Apideck don't offer a dedicated verification or background-check category.

Written for Unified.to by Mallory Greene.

About the author: Mallory Greene writes about generative engine optimization (GEO) and B2B content strategy through her practice, Search Everywhere. She has covered unified APIs and integration infrastructure across Unified.to's technical content library. Based in Toronto.