Best Unified API for ATS Integrations in 2026

June 10, 2026

Unified.to covers 157 ATS integrations and publishes, per integration, exactly which fields you can read and write and which webhook events fire, before you write a line of code. Every API call runs against the source ATS at request time, so no candidate data rests in the integration layer, and its ATS surface reaches background checks, assessments and job boards through the same connection.

That matters because recruiting integrations don't fail on the read path. They fail on the write path, and vendors differ in how much of it they document before you build. Merge (64 ATS integrations as of 2 October 2026, stores a synced copy) is the established enterprise option, with ISO 27001; Kombo is the HR-category specialist, with HRIS, ATS, assessment and LMS APIs on a sync-and-store architecture; Apideck, Knit and Truto fit narrower shapes. The right choice depends on which objects you need to write, on which specific ATS platforms, and on where your customers' candidate data ends up.

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. Some 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. It compares them 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 157 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 models ATS data as separate Common Models, including candidates, jobs, applications, interviews, scorecards, attachments, offers and screening questions, across 64 ATS integrations (as of 2 October 2026). Merge publishes the third-party endpoints it accesses per integration, and its published supported-fields matrices show which objects each integration can create or update. Architecture is sync-and-store: per Merge's own documentation, synced data is stored until actively deleted, normalized reads come from that copy, and records are as current as the last sync or source webhook (source webhooks on Professional and Enterprise). Merge is the right answer when operational maturity and HRIS-adjacent depth outweigh live source reads.

Kombo is the HR-category specialist, with separate unified APIs for HRIS and payroll, ATS, assessment and background check, and LMS. Its ATS model covers jobs, candidates, applications, interviews, offers, rejection reasons, tags, users, notes and scorecards. Kombo publishes 250+ integrations across those categories, with 122+ in its ATS connector index as of 8 October 2026, and its public docs list which integrations support each operation plus the fields and actions covered per integration. Architecture is sync-and-store: per Kombo's own documentation, data is mirrored into its database and reads are served from that store. On integrations without source webhooks, syncs run on a plan-dependent cadence with a 3-hour default, and a notification webhook tells your application to fetch the updated records. Kombo is the right answer for recruiting products whose core write is creating candidates and applications across many ATS platforms, and that accept reads served from 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 and applications, with no first-class interviews, scorecards, documents or offers, across roughly 10 ATS integrations as of 8 October 2026. Apideck shares the pass-through posture (no cached customer data), and its managed change detection is slow: virtual webhooks check typically every 24 hours, adjustable by plan. 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, with no stored records by its own account (it keeps hashes of synced records to detect changes), and webhook-driven delivery across 40 ATS apps in its docs (39 on its site, as of 8 October 2026). Its webhook-push model streams initial and delta syncs to your webhook endpoint, which means your application owns ingestion, ordering, and idempotency. Knit retries failed deliveries for up to 4 days and publishes no ordering guarantee. Its ATS model covers applications, candidates, jobs, offers, interviews and assessments, with interviews and offers nested on the application, and each endpoint page lists the apps that support it. Knit is the right answer for HR-leaning products that want a pass-through, webhook-driven architecture. (Its free Launchpad plan covers MCP servers only; the Unified API starts at $499 a month on Start Up, as of 8 October 2026.)

Truto publishes its integration and resource counts, roughly 27 ATS integrations and 17 normalized resources as of 8 October 2026, 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. Together they span 139 readable properties, with published writable and required-field counts and webhook event types for every one of its ATS integrations. 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 row in those two tables is a fact Unified.to can state because it measured it, and a fact some vendors leave you to discover in production. Read the scorecard row as the example that explains the whole category: very few ATS integrations support scorecard writes. The cause sits in the ATS platforms themselves, not in the unified layer: most don't allow external systems to write evaluation data. 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 on some 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: very few 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, where 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. Across the catalog there are 23 webhook event types, 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, with screening questions, tags, interviews, offers and rejections each standing alone, a single "show me this application" view becomes several API calls stitched together in your code (Merge's expand parameter returns related objects in one call). The checklist looks comprehensive in a sales comparison; the integration is where you pay for it.

For a concrete measure: Truto's ATS model has 17 objects, surfacing offers, reject reasons, tags, and job form fields 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 (592 integrations, where hired candidates become employees), Verifications (including Checkr, Certn, First Advantage, Socure, Verifiable, Yardstik; background checks as a first-class category, which no other general-purpose unified API in this comparison models as its own category), 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. Most other vendors in this comparison make 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 a post-application collaboration and communication platform 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 with two engineers, mapping the unified data model to its business model once instead of mapping each ATS individually. On ATS platforms without native webhooks, virtual webhooks keep its data in sync.

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 Merge publish write support per integration and field; Kombo, Apideck, Truto and Knit publish it at the operation level; the rest resolve it in a sales call.

Unified.to's answers are already public: 157 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.

Moving from another unified API? Unified.to publishes migration guides for Merge, Kombo and Apideck, plus an overview for other platforms; each maps authorization, API calls, pagination, webhooks and passthrough, and covers re-authorizing customers or importing credentials from your own OAuth apps.

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

Frequently asked questions

Which unified API supports the most ATS integrations?

By published counts, Unified.to lists 157 ATS integrations, Kombo 122+ in its ATS connector index (as of 8 October 2026), Merge lists 64 (as of 2 October 2026), Knit 40 in its docs, Truto roughly 27, and Apideck roughly 10 (as of 8 October 2026). Counts aren't like-for-like: every vendor's ATS category includes HRIS platforms with recruiting modules, job boards and assessment tools alongside dedicated applicant tracking systems, so check the specific systems your customers run. Both Unified.to and Kombo let you write assessment results back through their ATS APIs, and both offer a separate assessment API for vendors embedding into an ATS's native assessment module.

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 very few 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 uses virtual webhooks that detect changes and deliver events at a configurable interval, as frequent as every minute on paid plans, with the changed records included, so there's no follow-up fetch. Sync-and-store platforms sync into their own database and notify your application to fetch the updated records: Kombo on a 3-hour default configurable down to five minutes, Merge on its sync schedule: daily on Launch, faster on Professional and Enterprise. 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 (including Checkr, Certn, First Advantage, Socure, Verifiable, Yardstik) as its own unified API category alongside ATS, HR & Directory, Learning Management and Assessments, and is the only general-purpose unified API in this comparison with verification as a first-class category. Kombo has a separate Assessment & Background Check API, and assessment results can also be written back through its ATS API. Knit's ATS API adds assessment-package and candidate-assessment endpoints on Greenhouse, Ashby and SmartRecruiters (SmartRecruiters credential setup "in beta testing"), and its separate Assessment API sends invitations on two platforms (as of 8 October 2026). Merge and Apideck don't offer a dedicated verification or background-check category.

Written by Mallory Greene.

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